Perrin Harkins wrote:
>
> on 11/19/01 8:05 PM, Joshua Chamas at [EMAIL PROTECTED] wrote:
> > It has been a while, but here's a new set of Hello World benchmarks!
>
> There was a recent announcement of HTML::Template::JIT, and Template Toolkit
> has an XS option now. Any chance you could put tho
on 11/19/01 8:05 PM, Joshua Chamas at [EMAIL PROTECTED] wrote:
> It has been a while, but here's a new set of Hello World benchmarks!
There was a recent announcement of HTML::Template::JIT, and Template Toolkit
has an XS option now. Any chance you could put those into the next round?
- Perrin
Hey, [[ NUMBERS ARE BELOW ]]
It has been a while, but here's a new set of Hello World benchmarks!
What took me so long in getting these out is that the java web environments
that I had set up would keep crashing during the tests in ways that would
not only render their benchmarks meaningless, but
On Thu, Jan 04, 2001 at 09:55:39AM -0500, Blue Lang wrote:
> Eh, ab isn't really made as anything other than the most coarsely-grained
> of benchmarks. Concurrency testing is useless because it will measure the
> ratio of requests/second/processor, not the scalability of requests from
> single to
On Thu, 4 Jan 2001, Roger Espel Llima wrote:
> JR Mayberry <[EMAIL PROTECTED]> wrote:
> > Linux does serious injustice to mod_perl. Anyone who uses Linux knows
> > how horrible it is on SMP, I think some tests showed it uses as litle as
> > 25% of the second processor..
>
> A simple benchmark wit
JR Mayberry <[EMAIL PROTECTED]> wrote:
> The Modperl handler benchmark, which was done on a dual P3 500mhz on
> Linux does serious injustice to mod_perl. Anyone who uses Linux knows
> how horrible it is on SMP, I think some tests showed it uses as litle as
> 25% of the second processor..
It's an
[EMAIL PROTECTED] wrote:
>
> On Mon, Dec 18, 2000 at 10:37:16AM -0800, Joshua Chamas wrote:
> >
> > Please feel free to run the tests yourself, and if you give
> > me the results, I'll be sure to post them at a later date
> > at http://www.chamas.com/bench/ . You can grab the benchmarks
> > from
On Mon, Dec 18, 2000 at 10:37:16AM -0800, Joshua Chamas wrote:
>
> Please feel free to run the tests yourself, and if you give
> me the results, I'll be sure to post them at a later date
> at http://www.chamas.com/bench/ . You can grab the benchmarks
> from http://www.chamas.com/bench/hello.tar
JR Mayberry wrote:
>
> I strongly dislike the benchmarks on the below URL, its very
> misleading..
>
> The Modperl handler benchmark, which was done on a dual P3 500mhz on
> Linux does serious injustice to mod_perl. Anyone who uses Linux knows
> how horrible it is on SMP, I think some tests show
I strongly dislike the benchmarks on the below URL, its very
misleading..
The Modperl handler benchmark, which was done on a dual P3 500mhz on
Linux does serious injustice to mod_perl. Anyone who uses Linux knows
how horrible it is on SMP, I think some tests showed it uses as litle as
25% of the
Gunther Birznieks wrote:
> But it's a shame that the only way to
> get faster than PHP is to write a raw Mod_perl handler according to the
> benchmarks. All the other mod_perl tools seem slower.
It makes sense though. All the other tools do more setup work on each
request: parsing input, manipul
Hi all,
On Sun, 17 Dec 2000, Gerald Richter wrote:
> there are so many factors, so they are very difficult to compare.
True. But nevertheless I think it's a very useful bit of work because
the thing that stands out is that all (server) dynamic content comes at
a high cost in processor cycles.
> For the raw benchmarks...
>
> OK, I finally got a little time to download and read some the
hello.tar.gz.
>
> It's good to see TT is fairly fast. But it's a shame that the only way to
> get faster than PHP is to write a raw Mod_perl handler according to the
> benchmarks. All the other mod_perl
Gunther Birznieks wrote:
>
> For the raw benchmarks...
>
> OK, I finally got a little time to download and read some the hello.tar.gz.
>
> It's good to see TT is fairly fast. But it's a shame that the only way to
> get faster than PHP is to write a raw Mod_perl handler according to the
> benchm
For the raw benchmarks...
OK, I finally got a little time to download and read some the hello.tar.gz.
It's good to see TT is fairly fast. But it's a shame that the only way to
get faster than PHP is to write a raw Mod_perl handler according to the
benchmarks. All the other mod_perl tools seem
Hey,
Still very rough, the hello world benchmark suite is available
for download at: http://www.chamas.com/bench/hello.tar.gz
You may run it like:
# to get started, see what tests will run, note you
# may need some CPAN modules installed to get this far
perl ./bench.pl -test
# to run t
Joshua Chamas <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
> >
> > IME, simple mod_perl handlers typically run around 50% as fast as
> > HTML static pages. Your hello world benchmark seems to be slightly
> > misleading in this respect, since the content-length is small
> > relative to the
Joe Schaefer wrote:
>
> IME, simple mod_perl handlers typically run around 50% as fast as
> HTML static pages. Your hello world benchmark seems to be slightly
> misleading in this respect, since the content-length is small
> relative to the header size.
>
I'll send you my benchmark suite separ
Joshua Chamas <[EMAIL PROTECTED]> writes:
> RESULTS:
>
> [hello]# ./bench.pl -time=60
> ...
> Test Name Test FileHits/sec Total Hits Total Time Total
>Bytes
>
>
> HTML Stati
"Alexander Farber (EED)" wrote:
>
> Hi Joshua,
>
> you sort the table at http://www.chamas.com/bench/ by Hits/s,
> but the ModPerl Handler was tested on PIII-500 x 2 and the Java
> thingies below - only PII-266.
>
> Is it an intended joke or do I misunderstand something?
>
The first page is m
Hi Joshua,
Joshua Chamas wrote:
> Note, this is the first benchmark that I've run of Apache::ASP on
> Linux, which is nice to see because Linux is one of the faster OS's,
> and it now looks bit more of a player, compared to what's listed at
> http://www.chamas.com/bench/ when I benched it on Sola
Gunther Birznieks wrote:
>
> Then it seems odd that there is such a huge discrepency between CGI.pm and
> no CGI.pm. If you preload CGI.pm in startup.pl does the difference go away?
>
I did preload CGI.pm. I'll send you the hello world
suite separately since you seem curious. Note that at 500
Then it seems odd that there is such a huge discrepency between CGI.pm and
no CGI.pm. If you preload CGI.pm in startup.pl does the difference go away?
At 02:56 AM 12/11/2000 -0800, Joshua Chamas wrote:
>Gunther Birznieks wrote:
> >
> > Is CGI Raw decoding the get/post yourself? Or using the Apac
On Mon, 11 Dec 2000, Joshua Chamas wrote:
> Lastly, I was unable to get AxKit to run without segfaulting ...
http://axkit.org/faq.xml
Either you're running PHP on that server, or you have an Apache with expat
included. Do "nm /path/to/apache/bin/httpd | grep -i XML" to find out if
the latter is
Gunther Birznieks wrote:
>
> Is CGI Raw decoding the get/post yourself? Or using the Apache::args,
> Apache::Request::param mechanism?
>
In the hello world scripts, there is no get/post processing as
part of the benchmark. Here's the code that's run:
http://www.chamas.com/bench/#perlrawcgi
Is CGI Raw decoding the get/post yourself? Or using the Apache::args,
Apache::Request::param mechanism?
At 02:13 AM 12/11/2000 -0800, Joshua Chamas wrote:
>Hey,
>
>I have automated a portable Hello World test suite, but its not
>CPAN ready, so if any would like to contribute, run, and comment
>
Hey,
I have automated a portable Hello World test suite, but its not
CPAN ready, so if any would like to contribute, run, and comment
on the sources, give me a holler & I'll send them to you. What
it does is fire up a lean apache on a high port with only the
config necessary to run the benchmar
27 matches
Mail list logo
