> >
> > 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 it
>
> 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
ipOutput.
So, I reran hello/bench.pl w/ AxGzipOutput On and sped axkit up quite a bit.
attached are some diffs and a couple of 1 sec bench.pl runs. Would be
interesting to see how axkit compares now?
Thanks,
Ed
On Mon, Oct 14, 2002 at 12:26:06AM -0700, Josh Chamas wrote:
> Hey,
>
>
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
Perrin Harkins wrote:
>
> Despite the intentionally misleading nature of Microsoft's "benchmark",
> it did get me thinking about what sort of benchmarking options exist for
> comparing languages and platforms. The "Hello World" and "Hello 2000"
> benchmarks are pretty small (understandably so
Ray and Lara Recendez wrote:
> I am trying to get Apache::Hello to work.
<...>
> #!/usr/local/bin/perl
Turn PerlWarn On as described here:
http://perl.apache.org/src/mod_perl.html#SWITCHES
Also try running Apache in single-user mode:
/usr/local/apache/bin/apachectl -X
This he
On Mon, 17 Sep 2001 13:15:44 -0700
Ray and Lara Recendez <[EMAIL PROTECTED]> wrote:
> # vi Hello.pm
> "Hello.pm" 26 lines, 392 characters
> package Apache::Hello;
> # File: Apache/Hello.pm
>
> use strict;
> use Apache::Constants qw(:common);
>
>
PLEASE HELP.
I am trying to get Apache::Hello to work. I saved it as Hello.pm in
lib/perl/Apache. Below are my setup files and pertinent info. When I access
the virtual location (hello/world) from Apache's root directory, my browser
returns the following message: "The document c
On Thu, 10 Aug 2000, Ken Williams wrote:
> To clarify - some handlers can be called using object-oriented
> techniques, and some can't. The switch for this behavior is that the
> handler is prototyped with ($$).
or with newer Perls:
sub handler : method {...}
Ah I C, said the Perl man!
Thank you for the clarification.
At 09:55 AM 8/10/00 -0500, you wrote:
>[EMAIL PROTECTED] (G.W. Haywood) wrote:
>
>>Hi there,
>>
>>On Wed, 9 Aug 2000, George Sanderson wrote:
>>
>>> PerlModule Apache::Hello
>>>
>>&
[EMAIL PROTECTED] (G.W. Haywood) wrote:
>Hi there,
>
>On Wed, 9 Aug 2000, George Sanderson wrote:
>
>> PerlModule Apache::Hello
>>
>> SetHandler perl-script
>> PerlHandler Apache::Hello->handler
>>
>> #
>> Results in the followi
Hi there,
On Wed, 9 Aug 2000, George Sanderson wrote:
> PerlModule Apache::Hello
>
> SetHandler perl-script
> PerlHandler Apache::Hello->handler
>
> #
> Results in the following error_log output:
> [Sun Aug 6 21:48:02 2000] [error] Undefined subroutine
> &a
I have Apache 1.3.12 using mod_perl 1.24 as a DSO, built with Perl 5.6.0
which is running on Linux 2.2.14.
When the following is presented in the httpd.conf file:
#
PerlModule Apache::Hello
SetHandler perl-script
PerlHandler Apache::Hello->handler
#
Results in the following error_log out
31 matches
Mail list logo
