Well, I don't know APC, but I can try on the main aspects of mod_perl:
- The perl interpreter has been compiled into the server and is made
an integral part of all his child processes. Thus, no extra program
has to be loaded for the execution of a requested perl script.
- A certain startup script can be configured to preload often used
perl modules.
- The server has to be told (in httpd.conf) the scripts from which
directories are to be run under mod_perl.
In short, some of the more importent characteristics of the execution
with mod_perl are:
- DBI database connections will not be closed. On 'disconnect' or
script exit they are being returned to a configurable pool. This
happens transparently to the user. Usually nothing needs to be changed
in your script.
- Possibly most important for you: Modules are not unloaded on script
completion, but they are being cached in memory instead and are shared
between invocations across different scripts. This happens separately
for every apache instance. Each of the longrunning apache children
will have its own instance of any often used module.
Lets assume, for example, your server is configured to fork and
maintain 6 apache children. And some of your scripts, which are
executed with mod_perl, use a module MyLib.
Then each apache will load MyLib.pm when it is found to be missing on
first request. The module is kept in memory until it wasn't required
for some time and/or the place is needed. (This means that once you've
changed a module you will have to reload the apache unless it is
configured to detect such changes and auto reloads.)
Eventually you'll end up with 6 instances of MyLib in your system's
memory which are unaware of each other and bear no connection.
Each incoming HTTP request in succession may be handled by any of the
6 children. You can't possibly know which instance of your module will
handle a specific request and you don't need to.
Any module's initialization code (in the main block and outside of any
sub) is executed only once, when the module is loaded.
This way you can do expensive database lookups or calculations once
and then have the data available as long as the module lives in
memory.
The same tactic works with code. Transfer as much code as possible
from your scripts into subroutines of your modules. Then only the
small portion which is left has to be read and compiled with each
call.
And of course there are also some traps.
- Changing a module's global vars from a script can lead to
unpredictable results.
- All variables should always get properly initialized or else some
old values may survive and become visible between invocations.
- Never use the __END__ token in a script that's meant to be employed
with mod_perl.
....
There were several other things to observe which I can't remember
right know, but at least that should get you started.
You probably already know that the repository for mod_perl is at
apache.org and it's rather futile to point you towards the mounts of
tutorials and documentation which is available at that place.
I hope very much that my short introduction will help you to also
experience the enormous performance boost that's achievable with
mod_perl.
Cheers,
Steffen
