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!
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!
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!
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!
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('Run Time:
%.3f',($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) /
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 = "Thrash Test\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 / $Count\n";
}
$out.=sprintf('Run Time: %.3f',($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?
Hi there, On Tue, 17 Jun 2003, Trevor Phillips wrote: [snip] > The speed problem is not a connect time problem - it's actual run-time of the > Perl code. [snip] > The only common thing between all the systems with the problem is they're > using the i686 Debian package for mod_perl. 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. I'd always compile my own executables, if only so I know what's in there. 73, Ged.
Re: mod_perl slower than expected?
On Friday 13 June 2003 23:00, you wrote: > [ please keep it on the list ] Oops. Sorry. Used to mail lists auto-replying to the list. ^_^;; > On Fri, 2003-06-13 at 03:23, Trevor Phillips wrote: > > > I don't think so. Pretty standard Debian install, Perl 5.6.1... > > And you compiled both mod_perl and FastCGI yourself? No, they're the Debian binary packages. Would it make a difference, if they're using the same compile of Perl itself? The speed problem is not a connect time problem - it's actual run-time of the Perl code. I'm trying to narrow down what the problem is; I have a simple EDO script which is basically a bunch of nested iterations incrementing a counter. It contains no DB activity (just to show this isn't a DBI issue). I also ran it with the vanilla CGI version of the EDO parser, with the same result - everything is faster than running it under mod_perl. I've tried it on several different systems. Interestingly, the slow-down has occurred on all systems, with the exception being a Sun Sparc Ultra-5. All systems are running Debian, with a variety of Apache configs. There's also a mix of dual and single CPU, and a mix of Intel & AMD CPUs. The only common thing between all the systems with the problem is they're using the i686 Debian package for mod_perl. I'll continue trying different configs, and will also try recompiling mod_perl myself... > > That's preloaded for some other modules. EDO uses Apache::Registry. > > (Which is another possible point of suspicion, although it's not used > > much... And Apache::Registry is supposed to be faster than CGI (which the > > FastCGI version uses) too...) > > Apache::Registry is faster than a CGI script. The CGI.pm module does > something totally different, i.e. parsing params. CGI::Simple > implements the same interface and is a drop-in replacement, so it might > be worth a try. Oops! Sorry! I meant Apache::Request. I've never used Apache::Registry before. ^_^ > > Personally, I'd love to see a blend: Where I can have a light-weight > > mod_perl style interface in all daemons, which can interface to a > > possibly more limited number of FastCGIs. Gain the power of mod_perl, > > with the resource control of FastCGIs. > > You can do that with mod_perl 2, by setting up the number of perl > interpreters you want to have available for each script. See > http://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support Yes, I've heard many good things about Apache 2 & mod_perl 2, as well as many reasons not to shift everything to it yet. I look forward to the time it and I are ready to migrate. ^_^ -- . 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?
> Is there anything I may be missing about the general configuration or > environment of mod_perl which may be causing this strange situation? Try profiling... Some time ago I found my modperl app to be fairly slow because I turned on use Carp (and was carping errors and warnings). After disabling carping it was almost 10 times faster. I have also found that SWIG generated interface to some C++ library is very inefficient in some places (especially destructing a lot of objects) and manually written XS module happened to be a few times faster (it was the case with a lot of small objects). I think there are also other similar potential problems... -- ( Marcin Kasperski | Most of the bad things that can happen to a project ) ( http://www.mk.w.pl | are the result of miscommunication. (Booch) ) () ( Porady dla programisty Oracle: http://www.mk.w.pl/porady/porady_oracle )
Re: mod_perl slower than expected?
[ please keep it on the list ] On Fri, 2003-06-13 at 03:23, Trevor Phillips wrote: > > Two other possibilities are using a different version of Perl (like one > > with theads and one without), or accidentally using the wrong version of > > your modules. > > I don't think so. Pretty standard Debian install, Perl 5.6.1... And you compiled both mod_perl and FastCGI yourself? > > > PerlModule CGI; > > > > You could gain more speed by replacing that. CGI_Lite or CGI::Simple > > are faster and should still be cross-platform. > > That's preloaded for some other modules. EDO uses Apache::Registry. (Which is > another possible point of suspicion, although it's not used much... And > Apache::Registry is supposed to be faster than CGI (which the FastCGI version > uses) too...) Apache::Registry is faster than a CGI script. The CGI.pm module does something totally different, i.e. parsing params. CGI::Simple implements the same interface and is a drop-in replacement, so it might be worth a try. How does the performance compare in general? Apache::Registry is slower than writing your own handler, so it could be masking your speed gain to some degree. > > Why don't you run your own server? It's easy to do, even if everyone is > > on the same machine and using the same mod_perl build. > > I've never had a need to? Our dev server is close to our prod server in > config, to aid in testing possible issues & conflicts. I do it for the reason you mentioned, i.e. restart without disturbing anyone else. > > > As a FastCGI, all I have to do to restart it is touch the main CGI file. > > > > Does that restart the whole FastCGI daemon? Without affecting other > > people who are developing on it? > > Ummm, the script IS the daemon. mod_fastcgi knows how to talk to the FastCGIs, > and manages the loading (and killing) of them. Each FastCGI app runs as its > own persistent process, and you can either statically control the number of > processes, or give it a dynamic range to balance requests with. So it takes down the script, but that doesn't affect the rest of the developers because they aren't working on the same script? That makes sense. SpeedyCGI is similar, I believe. > So when a FastCGI is thrashing your CPU, top shows the actual CGI name, and > you can restart it by killing it, or, if enabled, by touching it, with no > effect on any apache daemons, or other FastCGIs. Showing the script name in top is a nice feature. With mod_perl you have to use something Apache::VMonitor for this. > > You can specify an exact number with apache if you want to. > > But again, that limits what else the server is doing. I could have an Apache > server with 50 daemons, used to deliver images, boring stuff, mod_perl stuff, > whatever, and still control my FastCGI's processes. Yes, this is true. In production I use a front-end proxy setup for this reason. > Personally, I'd love to see a blend: Where I can have a light-weight mod_perl > style interface in all daemons, which can interface to a possibly more > limited number of FastCGIs. Gain the power of mod_perl, with the resource > control of FastCGIs. You can do that with mod_perl 2, by setting up the number of perl interpreters you want to have available for each script. See http://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support - Perrin
Re: mod_perl slower than expected?
On Fri, Jun 13, 2003 at 01:16:48PM +0800, Trevor Phillips wrote: > On Friday 13 June 2003 12:26, Perrin Harkins wrote: > > > > You're not giving us much to go on here. What kind of changes did you > > make? Can you verify that you are running the correct versions of the > > modules under mod_perl? Are you seeing generally about the same > > performance on both platforms? What does you httpd.conf look like? > > Ok, EDO (the name of the app) parses HTML for additional custom markups, and > then executes functionality based on those markups (putting it very simply). > The general procedure for a request involves: > - Creating an EDO::Parser object > - Parsing HTML source into an internal structure (this can be cached to > avoid caching on every request) > - Executing instructions based on the parsed code > > The app does a lot of talking to databases - predominantly MySQL for testing. > Are you creating and then distroying a lot of database connections in your modules? Apache::DBI caches these connections saving you the connecton overhead. Not sure if FastCGI can do that. Just my thoughts Paddy
Re: mod_perl slower than expected?
Trevor Phillips wrote: On Friday 13 June 2003 13:57, Stas Bekman wrote: Since your question is too broad to be able to easily pinpoint any problems without spending some time with it, I'd suggest reading: http://perl.apache.org/docs/1.0/guide/performance.html if you haven't done that yet. I have. Although it was several years ago now. Has much changed? It wasn't updated much in the last year. But I did lots of updates a year before when working on the "Practical mod_perl" book. I'll take a look, but I haven't seen anything in there that correlates to the sort of results I'm seeing. This isn't a perl load-time issue, and it's not a small set slow-down - it's a percentage slow-down on pages of which can take up to 10 seconds to generate and return. It's something run-time, which is different between mod_perl and FastCGI. It's bizarre... As I said, if you were asking more specific question or showing code samples which are slower in mod_perl than they are in FastCGI, it'd be easier to know how to tune the setup. That's why sending you to the document was the best I could do in the current situation. Have you heard of Apache::Reload. http://perl.apache.org/docs/1.0/guide/porting.html#Reloading_Modules_and_Re quired_Files I have now. How does it handle syntax errors? Does it kill the whole server, keep the old module running, or just kill that module? it calls require(), so if that fails, the old version stays in memory. Nothing gets killed. I use it all the time and it saves me heaps of time. Give it a try. As a FastCGI, all I have to do to restart it is touch the main CGI file. I also have tighter control on the number of FastCGI processes, which is more useful for development. Looks like you may need to do some docs reading. You can easily get a total control over the number of mod_perl processes. It's all described here: http://perl.apache.org/docs/1.0/guide/performance.html Uh, yes, I can limit the Apache processes, but again, that will impact other users on the system. Really, FastCGI does just what I want, and it means I can write a module that works either as a FastCGI or a module. For content modules, that's fine. I've written a myriad of access modules, loggers, trans handlers, etc... For those, yes, they're mod_perl exclusives. But for some purposes, I find FastCGI more efficient. I'd almost be tempted to leave this app as a FastCGI - except for some places we use it we stack with other mod_perl content handlers. And I'm just baffled at this particular performance problem, since I have been through the standard things to check for. As Perrin said in his reply, we are always interested in features that can be added to mod_perl to make it more convenient to developers. Your answer so far doesn't give much insight on what FastCGI feature provides to control the number of processes in the multi-developers environment and is missing in mod_perl. I'm not familiar with FastCGI myself, so if you can be more specific about this feature, that would help. Thanks. __ 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?
On Friday 13 June 2003 13:57, Stas Bekman wrote: > > Since your question is too broad to be able to easily pinpoint any problems > without spending some time with it, I'd suggest reading: > http://perl.apache.org/docs/1.0/guide/performance.html > if you haven't done that yet. I have. Although it was several years ago now. Has much changed? I'll take a look, but I haven't seen anything in there that correlates to the sort of results I'm seeing. This isn't a perl load-time issue, and it's not a small set slow-down - it's a percentage slow-down on pages of which can take up to 10 seconds to generate and return. It's something run-time, which is different between mod_perl and FastCGI. It's bizarre... > Have you heard of Apache::Reload. > http://perl.apache.org/docs/1.0/guide/porting.html#Reloading_Modules_and_Re >quired_Files I have now. How does it handle syntax errors? Does it kill the whole server, keep the old module running, or just kill that module? > > As a FastCGI, all I have to do to restart it is touch the main CGI file. > > I also have tighter control on the number of FastCGI processes, which is > > more useful for development. > > Looks like you may need to do some docs reading. You can easily get a total > control over the number of mod_perl processes. It's all described here: > http://perl.apache.org/docs/1.0/guide/performance.html Uh, yes, I can limit the Apache processes, but again, that will impact other users on the system. Really, FastCGI does just what I want, and it means I can write a module that works either as a FastCGI or a module. For content modules, that's fine. I've written a myriad of access modules, loggers, trans handlers, etc... For those, yes, they're mod_perl exclusives. But for some purposes, I find FastCGI more efficient. I'd almost be tempted to leave this app as a FastCGI - except for some places we use it we stack with other mod_perl content handlers. And I'm just baffled at this particular performance problem, since I have been through the standard things to check for. -- . 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?
Trevor Phillips wrote: Benchmarking was done using an internal before and after check using Time::HiRes (as well as various stages during processing) as well as using "ab" to do multiple hits in succession. If you use multiple threads in ab, a sub-optimal setting for the number of processes can hurt mod_perl performance. Try to tune it so that it's about the same as FastCGI. Two other possibilities are using a different version of Perl (like one with theads and one without), or accidentally using the wrong version of your modules. I replaced it with my own module, which again parses/compiles expressions into an external structure once, rather than doing it every time. Hmmm. How do you cache these? PerlFreshRestart On Usually a bad idea... PerlModule CGI; You could gain more speed by replacing that. CGI_Lite or CGI::Simple are faster and should still be cross-platform. On a server where there are other developers working on it, if I restart the server, it can interrupt others working. Why don't you run your own server? It's easy to do, even if everyone is on the same machine and using the same mod_perl build. In addition, if I stuff something up badly (such as a minor syntax error), it doesn't kill the whole server. You mean on startup? As a FastCGI, all I have to do to restart it is touch the main CGI file. Does that restart the whole FastCGI daemon? Without affecting other people who are developing on it? With mod_perl I restart with 'apachectl stop && apachectl start'. I also have tighter control on the number of FastCGI processes, which is more useful for development. You can specify an exact number with apache if you want to. No objections to FastCGI; I just wondered if there was something we should be looking to add to mod_perl that would make it a more attractive dev environment for people who use FastCGI. I also work on FastCGI as a low-ish denominator. There's less server impact to throw a FastCGI on, than to install mod_perl, if it's not already there. If you're looking for an ISP-friendly approach to offer your potential users, check out SpeedyCGI aka PersistentPerl. It can be used without root access. - Perrin
Re: mod_perl slower than expected?
Trevor Phillips wrote: [...] Since your question is too broad to be able to easily pinpoint any problems without spending some time with it, I'd suggest reading: http://perl.apache.org/docs/1.0/guide/performance.html if you haven't done that yet. By the way, I don't understand your comment about how you developed with FastCGI because it's easy to restart. Is there something about mod_perl that makes it hard to restart for you? I always restart after every code change since it takes me less than a second to do. On a server where there are other developers working on it, if I restart the server, it can interrupt others working. In addition, if I stuff something up badly (such as a minor syntax error), it doesn't kill the whole server. Have you heard of Apache::Reload. http://perl.apache.org/docs/1.0/guide/porting.html#Reloading_Modules_and_Required_Files As a FastCGI, all I have to do to restart it is touch the main CGI file. I also have tighter control on the number of FastCGI processes, which is more useful for development. Looks like you may need to do some docs reading. You can easily get a total control over the number of mod_perl processes. It's all described here: http://perl.apache.org/docs/1.0/guide/performance.html __ 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?
On Friday 13 June 2003 12:14, Cees Hek: I'm far from new to mod_perl, so yes, I've checked all the obvious stuff. > - Are you only checking the first time you load the page? mod_perl still > needs to load all the perl modules on the first request to a page, unless > you have specifically pre-loaded them in the apache configuration. > Subsequent page loads should be faster. Benchmarking was done using an internal before and after check using Time::HiRes (as well as various stages during processing) as well as using "ab" to do multiple hits in succession. It is definitely cached code. Successive hits are using the persistent cached data as they should. > - are you using mod_perl2? I don't know enough about mod_perl2 to help > here, but possibly you are having thread issues with the threaded MPM. Nope. Definitely normal old mod_perl for Apache 1.3.x. > mod_perl should be just as fast as FastCGI as they achieve similar goals by > eliminating the perl startup and compile stages. If this doesn't help you, > then please provide more info on your setup. Hmmm. Problem is the config is complex, and the module itself is also very complex, so I didn't want to spam the list with tons of config info. I'll include some more info below... On Friday 13 June 2003 12:26, Perrin Harkins wrote: > > You're not giving us much to go on here. What kind of changes did you > make? Can you verify that you are running the correct versions of the > modules under mod_perl? Are you seeing generally about the same > performance on both platforms? What does you httpd.conf look like? Ok, EDO (the name of the app) parses HTML for additional custom markups, and then executes functionality based on those markups (putting it very simply). The general procedure for a request involves: - Creating an EDO::Parser object - Parsing HTML source into an internal structure (this can be cached to avoid caching on every request) - Executing instructions based on the parsed code The app does a lot of talking to databases - predominantly MySQL for testing. Minor optimisations were achieved by replacing some internal hash structures with arrays, using constants to index them. One major optimisation was replacing the conditional parsing module. I was using SQL::Statement, and fudging it to eval just the WHERE condition, to be able to do SQL-style conditionals. I replaced it with my own module, which again parses/compiles expressions into an external structure once, rather than doing it every time. As mentioned, these (and a few other misc changes) optimisations gave about a 25% speed boost for complex pages (such as long lists of data). Predominantly, it does lots of references and manipulations of arrays and hashes, it talks quite a bit to databases via DBI, and reads the occasional file from disk. It stores a persistent cache of "compiled" code, and it builds page output entirely in memory before output. All benchmarks I carried out on the same hardware platform, using the same HTML source files. The only thing I changed was whether it was parsed with the Apache Module version, or the FastCGI version. My Apache conf. is long and complex, since the systems I develop & tested this on do lots of other things. Config items that are related to mod_perl include: PerlFreshRestart On PerlModule Apache::Filter; PerlModule Apache::SSI; PerlModule CGI; PerlModule Apache::Resource; PerlSetEnv PERL_RLIMIT_AS 48:64 PerlChildInitHandler Apache::Resource I also use PerlRequire to pre-load several other modules used by the server. Although the mod_perl version of EDO can be used as an Apache::Filter, I turned it off for the benchmarks. > By the way, I don't understand your comment about how you developed with > FastCGI because it's easy to restart. Is there something about mod_perl > that makes it hard to restart for you? I always restart after every > code change since it takes me less than a second to do. On a server where there are other developers working on it, if I restart the server, it can interrupt others working. In addition, if I stuff something up badly (such as a minor syntax error), it doesn't kill the whole server. As a FastCGI, all I have to do to restart it is touch the main CGI file. I also have tighter control on the number of FastCGI processes, which is more useful for development. I also work on FastCGI as a low-ish denominator. There's less server impact to throw a FastCGI on, than to install mod_perl, if it's not already there. It's also closer to the normal CGi version of EDO, and the command-line version. If you want to know more about EDO itself, I've had it on Sourceforge for a while now: http://sourceforge.net/projects/edo/ Still, documentation is a little sketchy there, and it's still under development, even though it's used in production-level sites where I work. -- . Trevor Phillips - http://jurai.murdoch.edu.au/ . : Web Technical Ad
Re: mod_perl slower than expected?
Trevor Phillips wrote: My latest set of changes have resulted in optimisation and given a decent speed increase of up to 25% (depending on the exact usage) for complex pages. However, when I used the revised modules with the Apache Module, I'm only getting a marginal performance increase! You're not giving us much to go on here. What kind of changes did you make? Can you verify that you are running the correct versions of the modules under mod_perl? Are you seeing generally about the same performance on both platforms? What does you httpd.conf look like? By the way, I don't understand your comment about how you developed with FastCGI because it's easy to restart. Is there something about mod_perl that makes it hard to restart for you? I always restart after every code change since it takes me less than a second to do. - Perrin
Re: mod_perl slower than expected?
Quoting Trevor Phillips <[EMAIL PROTECTED]>:
> However, when I used the revised modules with the Apache Module, I'm only
> getting a marginal performance increase!
>
> Since the bulk of the work is being done by modules common to the Apache and
>
> FastCGI front-ends, I am at a loss as to explain why there is such a vast
> difference in performance.
>
> Is there anything I may be missing about the general configuration or
> environment of mod_perl which may be causing this strange situation?
You would have to provide your configuration for anyone to be sure, but there
are a couple of things to check for:
- Are you only checking the first time you load the page? mod_perl still needs
to load all the perl modules on the first request to a page, unless you have
specifically pre-loaded them in the apache configuration. Subsequent page loads
should be faster.
- Are you sure you are running the script under mod_perl? try checking for
$ENV{MOD_PERL} in the script you are executing. If it is not defined, then you
are not running the script under mod_perl.
- Could it be that you have a small number of child processes running, or are in
single-process mode, and your HTML page has several images on it? This could
affect the speed at which the page displays (although you should see it with
FastCGI as well). Your safest bet is to use something like wget or the LWP
scripts to get the page, and then you can easily time it.
- are you using mod_perl2? I don't know enough about mod_perl2 to help here,
but possibly you are having thread issues with the threaded MPM.
mod_perl should be just as fast as FastCGI as they achieve similar goals by
eliminating the perl startup and compile stages. If this doesn't help you, then
please provide more info on your setup.
Cheers,
Cees
mod_perl slower than expected?
I am baffled! I have a quite complex application. Actually, it's more like a language. (Yes, a language written in Perl... ^_^) I've written it as Perl Modules, and I have a number of front-ends: normal CGI, FastCGI, command line, and Apache Module. When doing development, I predominantly work with the FastCGI front-end, since it's easy to restart, and still gives persistence between requests. My latest set of changes have resulted in optimisation and given a decent speed increase of up to 25% (depending on the exact usage) for complex pages. However, when I used the revised modules with the Apache Module, I'm only getting a marginal performance increase! Since the bulk of the work is being done by modules common to the Apache and FastCGI front-ends, I am at a loss as to explain why there is such a vast difference in performance. Is there anything I may be missing about the general configuration or environment of mod_perl which may be causing this strange situation? -- . 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) /
