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, there are more things to go wrong and greater need for careful testing. The error_log is going to be your best friend. Make sure that correct line numbers are enabled when you compile mod_perl, and you may want to use Carp at runtime to get fuller error messages.