> >
> > Yes, Embperl per default caches a "compiled" version of the
> > stylsheet in
> > memory.
> >
> > Gerald
> >
> > P.S. There are also options to cache the result of the xslt
> > transformation
> > or any itermediate steps
> >
>
> Oh - A way of making it even faster in the benchmarks?
>
Yes,
> From: Gerald Richter [mailto:[EMAIL PROTECTED]
>
> Yes, Embperl per default caches a "compiled" version of the
> stylsheet in
> memory.
>
> Gerald
>
> P.S. There are also options to cache the result of the xslt
> transformation
> or any itermediate steps
>
Oh - A way of making it even faste
>
> This differs from Embperl where the application layer itself handles
> the XSLT rending, not the script/XML file:
>
> PerlSetEnv EMBPERL_RECIPE LibXSLT
> PerlSetEnv EMBPERL_XSLTPROC libxslt
> PerlSetEnv EMBPERL_XSLTSTYLESHEET $ROOT/hello.xsl
>
> So perhaps Embperl 2 is able to do
Ask Bjoern Hansen wrote:
On Tue, 4 Mar 2003, Josh Chamas wrote:
I thought it was interesting that Embperl 2 (barely) beat out PHP 4.3.0
on XSLT in both the XSLT Hello & XSLT Big tests.
Why is that interesting? A bit more background would be
interesting. :-) (post it to the list maybe).
My ex
Hey,
I have published the latest Hello World benchmarks, available at:
http://chamas.com/bench/
Just updated are:
- PHP 4.3.0 built with domxml extensions for XSLT tests
- HTML::Embperl 1.3.6
- HTML::Mason 1.19
The PHP XSLT test are new, and the performance is similar is Embperl2 and
>
> FYI, I reposted the benchmarks without the MaxRequestsPerChild 100 set
> for HTML::Mason & Template Toolkit, as it was only Embperl 2.x that
> needed it.
>
Embperl 2.0b8 has still some real memory leaks. That's why it called beta.
Of course they will be fixed before the final release of 2.0.
Hey,
I updated the Apache Hello World Benchmarks with some major updates:
AxKit config fixed XSLT performance
Cocoon XSLT benchmarks added
Tomcat updated to 4.1.12
Check them out at http://chamas.com/bench/
Regards,
Josh
Ed wrote:
> Hi,
>
> (as far as i can tell after a quick peek at the code and some debugging)
>
> It looks like there is a bug w/ AxKit::run_axkit_engine() and/or
> Apache::AxKit::Cache::_get_stats()
>
This is really great Ed. Adding the AxGzipOutput On config to the XSLT
tests in the benchmar
Dave Rolsky wrote:
> On Mon, 14 Oct 2002, Josh Chamas wrote:
>
>
>>This is interesting. I should look into upgrading to perl 5.8 on
>>these tests & see what difference there may be.
>>
>>You might also see if it makes a difference if you run the tests for
>>a long enough time. I run them at le
The Apache Hello World benchmarks are updated at
>
> http://chamas.com/bench/
>
> The changes that affect performance numbers include:
>
> Set MaxRequestsPerChild to 1000 globally for more realistic run.
>
> Set MaxRequestsPerChild to 100 for applications that seem
On Mon, 14 Oct 2002, Josh Chamas wrote:
> This is interesting. I should look into upgrading to perl 5.8 on
> these tests & see what difference there may be.
>
> You might also see if it makes a difference if you run the tests for
> a long enough time. I run them at least 60 seconds for these be
Dave Rolsky wrote:
>
> I'm fairly sure, FWIW, that Mason does not have any memory leaks, as of
> 1.12. Pre-1.10 versions do have a _very_ slow memory leak, and 1.10 and
> 1.11 had that leak plus another, much nastier one.
>
Yes, Mason seemed pretty free of leaks when I tested it more today too
Perrin Harkins wrote:
> Josh Chamas wrote:
>
>> Set MaxRequestsPerChild to 100 for applications that seem to leak
>> memory which include Embperl 2.0, HTML::Mason, and Template Toolkit.
>> This is a more typical setting in a mod_perl type application that
>> leaks memory, so should be fai
On Tue, 15 Oct 2002, Perrin Harkins wrote:
> Josh Chamas wrote:
>
> > Set MaxRequestsPerChild to 100 for applications that seem to leak
> > memory which include Embperl 2.0, HTML::Mason, and Template Toolkit.
> > This is a more typical setting in a mod_perl type application that
> > leaks
Josh Chamas wrote:
> Set MaxRequestsPerChild to 100 for applications that seem to leak
> memory which include Embperl 2.0, HTML::Mason, and Template Toolkit.
> This is a more typical setting in a mod_perl type application that
> leaks memory, so should be fairly representative benchmark s
Hey,
The Apache Hello World benchmarks are updated at
http://chamas.com/bench/
The changes that affect performance numbers include:
Set MaxRequestsPerChild to 1000 globally for more realistic run.
Set MaxRequestsPerChild to 100 for applications that seem to leak
memory which
Hi Josh,
On Tue, 30 Jul 2002, Josh Chamas wrote:
> Thanks for the feedback & still looking for more!
Well for one thing you're doing a great job. :)
Fo benchmarks to be more realistic, I feel that they need to include
chunks of code to do lookups in serious databases, put together very
complex
Josh Chamas wrote:
> My only problem with Apache::DBI for a benchmark is its
> default ping of the db per connect().
Oh, you're right I wasn't thinking about that. It is important in a
benchmark to be testing equivalent functionality as much as possible,
although it's very difficult to do.
>
Perrin Harkins wrote:
>
> To answer the original question, I don't think Apache::DBI is much
> overhead at all. It amounts to little more than a hash lookup.
> Certainly less work than the the thread synchronization required for
> connection pooling.
>
My only problem with Apache::DBI for a
Dennis Haney wrote:
>>The bias in the test is even a little slanted towards the JSP
>>benchmarks since the trivial connection pooling I used there is
>>nothing like the Apache::DBI overhead in the mod_perl test, when I
>>could have just used a persistent global $dbh instead. ( maybe I
>>should? )
> The bias in the test is even a little slanted towards the JSP
> benchmarks since the trivial connection pooling I used there is
> nothing like the Apache::DBI overhead in the mod_perl test, when I
> could have just used a persistent global $dbh instead. ( maybe I
> should? )
I believe you shou
Hey,
The Apache Hello World Benchmarks are updated at:
http://chamas.com/bench/
They now include 2 C Apache API benchmarks which show the fastest
the benchmarks can run at, and how mod_perl is not much slower!
Also included is a new HelloDB benchmark which is a trivial
connection/query of
urce code is available.
>
It would be good to see someone do this for mod_perl. None
of the benchmarks I have done so far get anywhere near testing
the scalability of systems in the real world, and it would
be good to see this done.
As a next step for the hello world benchmarks, I'll pr
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.
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 meanin
Hey,
It seemed that running the hello world benchmarks last time for only
60 seconds had problems with reproducibility, especially with mod_caucho.
So here's some numbers for ~ 10 minute run. Its actually something
like 20 benchmarks run for 30 seconds a piece, and the results s
Joshua Chamas wrote:
>
> mod_caucho
> used to look a lot faster, but my testing methodology changed.
> I used to take the results of the second benchmark run, and
> publish those, but this time only ran the -test for minor
> caching after starting resin ( & tomcat ). So, I'm gue
On Wed, 11 Jul 2001, Philip Mak wrote:
> And sorry for my newbie-ish question, but what is the difference
> between "mod_perl handler" and "Apache::Registry mod_perl"?
http://perl.apache.org/guide/performance.html#Apache_Registry_PerlHandler_vs_
including the benchmarks
___
Perrin Harkins wrote:
>
> > I do feel that compile time matters, but really with 60 seconds
> > and high MaxRequestsPerChild, these systems are getting plenty
> > of compiling caching.
>
> The thing is, if mod_caucho takes 5 seconds the first time it hits each
> template, but is the fastest afte
> I do feel that compile time matters, but really with 60 seconds
> and high MaxRequestsPerChild, these systems are getting plenty
> of compiling caching.
The thing is, if mod_caucho takes 5 seconds the first time it hits each
template, but is the fastest afterwards, these numbers don't give a ve
Perrin Harkins wrote:
>
> > mod_caucho
> > used to look a lot faster, but my testing methodology changed.
> > I used to take the results of the second benchmark run, and
> > publish those, but this time only ran the -test for minor
> > caching after starting resin ( & tomcat ). S
Good work as usual, Joshua.
> mod_caucho
> used to look a lot faster, but my testing methodology changed.
> I used to take the results of the second benchmark run, and
> publish those, but this time only ran the -test for minor
> caching after starting resin ( & tomcat ). So, I'
Good work as usual, Joshua.
> mod_caucho
> used to look a lot faster, but my testing methodology changed.
> I used to take the results of the second benchmark run, and
> publish those, but this time only ran the -test for minor
> caching after starting resin ( & tomcat ). So, I'
Philip Mak wrote:
>
> One thing caught my eye; how come "mod_perl handler" (808.4 hits per
> second) performed better than "HTML static" (768.2 hits per second)?
>
Here are my comments on this from the original post:
HTML static
for the first time, looks slower on my system than mod_perl.
One thing caught my eye; how come "mod_perl handler" (808.4 hits per
second) performed better than "HTML static" (768.2 hits per second)?
And sorry for my newbie-ish question, but what is the difference
between "mod_perl handler" and "Apache::Registry mod_perl"?
Hey,
The latest Hello World benchmarks at available at:
http://www.chamas.com/bench/hello.tar.gz
To reproduce the BELOW results on your platform, for
whatever tests are available, run:
./bench.pl -test
./bench.pl -version -time=60
--Josh
DISCLAIMER: these benchmarks test only what they
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
> Thanks Rudy! Any way you could throw some
> of the others into the mix, like Apache::ASP,
> Embperl, Mason, Registry CGI ? The more
> data there is, the more useful the benchmarks
> are, since some of the greatest value comes
> from how they compare on the same system.
>
> I understand if not
Thanks Rudy! Any way you could throw some
of the others into the mix, like Apache::ASP,
Embperl, Mason, Registry CGI ? The more
data there is, the more useful the benchmarks
are, since some of the greatest value comes
from how they compare on the same system.
I understand if not since these ben
Here are some new stats for Joshua's benchmarks:
http://www.chamas.com/bench/index.html
--
Machine:
OS: FreeBSD 4.0-STABLE
cpu: PII-300
session: no
client: ab
From: local
Notes: I had to tune the TCP/IP stack...
FreeBSD straight off the web does not
ha
64 matches
Mail list logo
