Take Home Message: Optimizations
April 10, 2000
It is tempting and simple to walk away from an introduction to
mod_perl thinking that it magically takes care of all optimizations.
The magical mod_perl genie just compiles your Perl and everything
is milk and honey. Not so fast! The ways in which mod_perl compiles
and caches code varies depending on how it is used -- before we
become immersed in details next month, go to sleep tonight with
a good overview of the ways in which mod_perl can optimize Perl
execution.
"Better Than Nothing" Optimization:
If your scripts will not (yet) run under Apache::Registry,
substitute the module Apache::PerlRun. This simplest form of
optimization will only keep the Perl interpreter inside the Apache
server, saving the need to fork a Perl interpreter for each script
execution. The savings here are small, but is still faster than
pure forking.
"Hands Off" Optimization:
Your script runs under Apache::Registry, but you are too
busy/tired/lazy/hungry to further adapt the environment for better
optimization. Mod_perl will have to compile both your modules and
your scripts once per child server process. When a request is
handed to a child process that has not yet invoked the script, the
script and modules will need to again be recompiled. Subsequent
requests served by that child can rely on the already-compiled
code in memory.
"Typical" Optimization:
You pre-load your Perl modules by including them via a
PerlModule or PerlRequire directive in Apache's
httpd.conf file. In doing so, the Apache parent now
possesses the compiled code for these modules in memory. When a
child is spawned, that child inherits the pre-compiled modules,
but the child must still compile the main Perl script itself once
per process. The compiled script is cached for future requests
handled by this child. This is probably the most common level of
mod_perl optimization, as it balances Apache parent size against
compilation time.
"Extreme but Bloated" Optimization:
It is even possible to give all the Perl code to Apache,
compiled into the parent process. Each child would then have no
code to compile, as it would inherit all pre-compiled code from
the parent. While potentially fastest, this also consumes the most
memory, as each child possesses compiled code that it may not use,
depending on how many scripts the site uses. Certain benchmarks
indicate that the time saved versus Typical Optimization is not
generally worth the extra memory consumption, but there are
probably exceptions which would benefit from Extreme but Bloated
Optimization.
Additional Resources:
Start Your Coding
The Perl You Need to Know
The Perl You Need to Know Special: Introduction to mod_perl Part 2
|
