Re: mod_perl slower than expected? - Test Code!
Hi there, On Wed, 18 Jun 2003, Trevor Phillips wrote: Whether it's i686 or i386 - both mod_perl and FastCGI are using the same compile of perl - so what difference should there be? Must have got my wires crossed somewhere - I thought you must be using different Perls. 73, Ged.
Re: mod_perl slower than expected? - Test Code!
Trevor Phillips [EMAIL PROTECTED] writes: [...] On my main dev box, ab gives an average of 8.8secs for the mod_perl run, and 7.2secs for the FastCGI run. The internal timer and printed output reflects these results too. How does the cgi/command-line version stack up? AFAICT your test isn't measuring any architectural differences between modperl and fastgci, just how well the server's embedded perl interpreter performs relative to perl itself. I wonder if compiling modperl as a DSO versus compiling it statically might explain the performance lag. -- Joe Schaefer
Re: mod_perl slower than expected? - Test Code!
Joe Schaefer wrote:
Trevor Phillips [EMAIL PROTECTED] writes:
[...]
On my main dev box, ab gives an average of 8.8secs for the mod_perl
run, and 7.2secs for the FastCGI run. The internal timer and printed
output reflects these results too.
How does the cgi/command-line version stack up? AFAICT your test isn't
measuring any architectural differences between modperl and fastgci,
just how well the server's embedded perl interpreter performs relative to
perl itself. I wonder if compiling modperl as a DSO versus compiling it
statically might explain the performance lag.
I doubt that this makes any difference. I think what makes the difference is
the fact that the mod_perl handler is setup via .htaccess. Have you tried
setting it in httpd.conf? Otherwise it's parsed on each request, no surprises
that it's slower.
Also add:
PerlModule Thrash
PerlModule Apache::Request
to your httpd.conf to pre-compile the modules.
Moreover, your code loads Apache::Request, but doesn't use it.
Unrelated to the case, but related to performance in general:
eval use Time::HiRes;;
if (!$@)
{
$Thrash::UseTimeHiRes = 1;
}
is probably a bit faster as:
eval { require Time::HiRes };
if (!$@)
{
$Thrash::UseTimeHiRes = 1;
}
and neater as:
use constant UseTimeHiRes = eval { require Time::HiRes };
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl slower than expected? - Test Code!
Stas Bekman wrote:
Joe Schaefer wrote:
I doubt that this makes any difference. I think what makes the
difference is
the fact that the mod_perl handler is setup via .htaccess. Have you
tried setting it in httpd.conf? Otherwise it's parsed on each request,
no surprises that it's slower.
Eh? How can that make a difference? Yes, I know that, between .htaccess
vs httpd.conf vs FastCGI vs CGI there will be some small performance hit
when accessing the URL. But that speed difference is irrelevant given
the run time of the content generator. I'm not talking about a
lightning-fast routine on a heavily hit server; I'm talking about a
complex request whose time can be measured in whole seconds. In that
scenario, .htaccess vs httpd.conf is irrelevant.
(And in my dev environment, both the FastCGI and mod_perl were being
configured from .htaccess)
And on the topic of DSO vs Static, yes, I tested that today. The static
mod_perl was marginally faster than the DSO mod_perl - but still nowhere
near as fast as the FastCGI, CGI and command line versions.
Interestingly, I tried Thrash on the aforementioned anomaly: My Sun Box
running Debian. I was wrong in saying the performance was the same for
both versions - turns out the mod_perl version on THAT platform is
slightly FASTER (but nowhere near the performance gap shown on the Intel
platforms).
Moreover, your code loads Apache::Request, but doesn't use it.
Oops. Kick-back from the original module I was cloning.
Again, though, that would only affect start-up time, which in this test,
is marginal. Also, it would not affect the time shown by the internal
time difference displayed.
Unrelated to the case, but related to performance in general:
eval use Time::HiRes;;
if (!$@)
{
$Thrash::UseTimeHiRes = 1;
}
is probably a bit faster as:
eval { require Time::HiRes };
if (!$@)
{
$Thrash::UseTimeHiRes = 1;
}
and neater as:
use constant UseTimeHiRes = eval { require Time::HiRes };
Thanks for the syntax tips. I'll change my other code to use them. ^_^
--
. Trevor Phillips - http://jurai.murdoch.edu.au/ .
: Web Technical Administrator - [EMAIL PROTECTED] :
| IT Services- Murdoch University |
| On nights such as this, evil deeds are done. And good deeds, of /
| course. But mostly evil, on the whole. /
\ -- (Terry Pratchett, Wyrd Sisters) /
Re: mod_perl slower than expected? - Test Code!
On Tuesday 17 June 2003 18:18, Ged Haywood wrote:
Do you know for sure that the Per was compiled for i686? Maybe it was
compiled for i386, so it would run on just about anything but it can't
use a lot of the faster features found in later processors.
Whether it's i686 or i386 - both mod_perl and FastCGI are using the same
compile of perl - so what difference should there be?
Right! I've put together a test case, which has nothing to do with my EDO
project. It's just a simple iterative loop, with subroutine calls, updating a
hash. I've included the main module Thrash.pm, which does the work, and
doubles as the mod_perl Apache module. I've included a FastCGI version, and a
plain CGI version (which can also be run from the command line), all using
Thrash.pm. I've also attached a .htaccess file setting up thrash.html to be
handled by Thrash.pm.
On my main dev box, ab gives an average of 8.8secs for the mod_perl run, and
7.2secs for the FastCGI run. The internal timer and printed output reflects
these results too.
Interestingly, the time to clear the hash after building it is quite large.
^_^
I commented out the hash adding code, to remove the hash processing, and leave
it more as a subroutine call test, but mod_perl was still slower, with
benchmarks of 3.7secs for mod_perl, and 2.7secs for FastCGI.
I've only tested this on one server so far. I'll test it on others now... I'd
be interested to hear if others get this discrepancy on their servers...
--
. Trevor Phillips - http://jurai.murdoch.edu.au/ .
: Web Technical Administrator - [EMAIL PROTECTED] :
| IT Services- Murdoch University |
| On nights such as this, evil deeds are done. And good deeds, of /
| course. But mostly evil, on the whole. /
\ -- (Terry Pratchett, Wyrd Sisters) /
package Thrash;
$Count = 0;
%Hash = ();
use Apache::Constants qw(:common);
use Apache::Request ();
eval use Time::HiRes;;
if (!$@)
{
$Thrash::UseTimeHiRes = 1;
}
sub handler
{
my $r = shift; # The Raw handler...
$r-send_http_header;
$r-print(Thrash::DoIt());
return OK;
}
sub DoIt
{
my $TIME_start = ($UseTimeHiRes?Time::HiRes::time():time());
my $out = H1Thrash Test/H1\n;
$Count = 0;
%Hash = ();
foreach my $A (qw(0 1 2 3 4 5 6 7 8 9 A B C D E F))
{
SubThrash(0,$A);
$out.=$A / $CountBR\n;
}
$out.=sprintf('BRun Time: %.3f/B',($UseTimeHiRes?Time::HiRes::time():time())-$TIME_start);
%Hash = (); # Clear Hash now we're done.
return $out;
}
sub SubThrash
{
my ($depth,$key) = @_;
if ($depth==3)
{
$Count++;
# $Hash{$key} = $Count;
return;
}
foreach my $B (qw(a b c d e f g h i j k l m n o p q r s t u v w x y z))
{
SubThrash($depth+1,$key.$B);
}
}
1;
thrash.cgi
Description: Binary data
thrash.fcgi
Description: Binary data
.htaccess
Description: Binary data
Re: mod_perl slower than expected? - Test Code!
On Wednesday 18 June 2003 11:30, Trevor Phillips wrote:
On my main dev box, ab gives an average of 8.8secs for the mod_perl run,
and 7.2secs for the FastCGI run. The internal timer and printed output
reflects these results too.
Oops! The internal timer wasn't accurate: Swap lines 35 36 of Thrash.pm, so
the timer happens AFTER the hash is reset:
%Hash = (); # Clear Hash now we're done.
$out.=sprintf('BRun Time:
%.3f/B',($UseTimeHiRes?Time::HiRes::time():time())-$TIME_start);
--
. Trevor Phillips - http://jurai.murdoch.edu.au/ .
: Web Technical Administrator - [EMAIL PROTECTED] :
| IT Services- Murdoch University |
| On nights such as this, evil deeds are done. And good deeds, of /
| course. But mostly evil, on the whole. /
\ -- (Terry Pratchett, Wyrd Sisters) /
