Additionally, mod_perl allows Perl code to be cached, so that Perl modules and scripts only needed to be loaded and compiled once. From then on, they are served from the web server's cache. This results in far faster processing times - reports indicate that speed increases of 200% to 2000% faster than Perl are possible.
mod_perl requires, tighter, more precise perl code to be written than CGI. CGI allows sloppier, less precise programming practices to be used. Additionally, it is possible to use Perl code for response handling to completely replace the Common Gateway Interface (CGI).
The reason that CGI programming is more relaxed, is because CGI scripts run as a single HTTP request, with a separate process for each HTTP request. When the request is completed, the process cleanly finishes. If a script is run under mod_perl, it can persist for several requests, and additionally, different scripts can exist in the same process.
The key to making code portable between CGI scripts and mod_perl, is to write clean, precise code from the start. It cannot be emphasised enough that any Perl code, whether for mod_perl or CGI, should use strict and have the -w flag. This way, it forces the code to be more precise, which results in cleaner code, and hence makes the code more likely to be portable between CGI and mod_perl.
As a simple example of how one should change Perl code to ensure it works under mod_perl, take the case of a simple undefined variable, declared in the main body of the code as follows:
| my $variable_name; |
Running under mod_perl, this would need to be declared and explicitly initialised as an undefined variable. So the code would be re-written as:
|
use vars qw($variable_name);
$variable_name = undef; |