Phoenix.pm: mod_perl

Andrew Johnson lajandy at yahoo.com
Wed Mar 27 23:05:08 CST 2002


--- Lowell Hamilton <syz at broken-bit.com> wrote:
[snip]
>  
> > http://perl.apache.org/dist/cgi_to_mod_perl.html
> Yeah but that's just basic stuff

Have you also checked the mod_perl Guide?  (Oh, wait, they moved it.) 
Here you go:

http://take23.org/docs/guide/

The Guide used to be the only documentation, then Doug Mac wrote the
mod_perl O'Reilly book.  I haven't checked it in awhile, but it should
have some valuable info in there.
 
> > I would also like to issue a STERN WARNING:
> <snip>
> 

Yeah, sorry 'bout that; I just get a bit defensive because some people
still sneer at mod_perl and its users, mostly based on their own
(failed) attempts at trying to make it work.  In fact, I recently had
(another) argument with my former boss about mod_perl (and I don't even
work for him anymore)!

> Nah I'm not aiming for just a "change two lines and go" approach .. I
> aiming for moving a large portion of the code out to apache modules. 
> I've just heard so many horror stories from people about it and am
> looking for resources for _good_ mod_perl code design (there isn't
> much
> to find outside of CPAN and apache) from the standpoint of taking an
> existing app and optimizing speed.  
> 

I think this part of the mod_perl Guide should be helpful then:

http://take23.org/docs/guide/porting.xml

This will make some people in the audience have stomach discomfort, but
my general rule for mod_perl programming is *put everything in a
module.*  Use the 'use strict' pragma *at all times.*  Only use package
globals unless all the programs for all the sites on the server need to
see a particular variable (because globals in mod_perl are just that:
global to every daemon and every site being served!).  

An added benefit to putting all code in Perl modules (besides memory
protection) is pre-compilation.  Any modules used in your startup.pl
file (or equivalent) are compiled at startup time into the main server
process, and are shared amongst all the child processes.  This saves
both compilation time and memory, since you can make sure the modules
you want are compiled in memory only once and stay there until the
server is shutdown.

> 50% of it is pretty clean homebrew CGI::Application-ish style code
> currently running under Apache::PerlRun with Apache::DBI connection
> pooling on a dedicated application-only mod_perl box proxied through
> the
> static servers on the outside .. but at peaks when receiving over 50
> script hits a second, the app server starts getting behind due to
> compilation waiting, even using the built-in intrepeter of PerlRun. 
> I'm
> benchmarked the scripts down as small as they will go but still about
> 25% of total execution time is compilation.  
> 

Interesting...I never played much with Apache::PerlRun.  I'd check out
rewriting the code into Perl modules and pre-loading them at startup
(that should at _least_ cut down on compilation time).  Also try using
Apache::Registry or even writing your app as full Apache modules
(scripts running in Apache::Registry and Apache::PerlRun are always
going to be slower and consume more memory than full Apache modules). 
Definitely check out the mod_perl Guide; I bet it'll have some info to
help you out!



=====


__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/



More information about the Phoenix-pm mailing list