How mod_perl Works
The principle of mod_perl is simple enough: Perl is loaded into Apache when it starts up — which makes for very big Apache child processes. This saves the time that would be spent loading and unloading the Perl interpreter but calls for a lot more RAM.
If you use Apache::PerlRun
, you get
a half-way environment where Perl is kept in
memory but scripts are loaded each time they are run. Most CGI
scripts will work right away in this environment.
If you go whole hog and use Apache::Registry
, your
scripts will be loaded at startup too, thus saving the overhead of
loading and unloading them. If your scripts use a database manager,
you can also keep an open connection to the DBM, and so save time
there as well (see later). Good as this for execution speed, there is
a drawback, in that your scripts now all run as subroutines below a
hidden main program. The problem with this, and it can be a killer if
you get it wrong, is that global variables are initialized
only when Apache starts up. More of this
follows.
The problems of mod_perl — which are not that serious — almost all stem from the fact that all your separate scripts now run as a single script in a rather odd environment.
However, because Apache and Perl are now rather intimately blended, there is a corresponding fuzziness about the interface between them. Rather surprisingly, we can now include Perl scripts in the Apache Config file, though we will not go to such extreme lengths here.
Since things are more complicated, ...
Get Apache: The Definitive Guide, 3rd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.