Web Server Programming with mod_perl (Perl in a Nutshell, 2nd Edition)

A common criticism of CGI is that it requires forking extra processes each time a script is executed. If you have only a few hits an hour, or even a few hits a minute, this isn't a big deal. But for a high-traffic site, lots of repeatedly spawning CGI scripts can have an unfortunate effect on the machine running the web server. The CGI scripts will be slow, the web server will be slow, and other processes on the machine will slow to a crawl.

The solution to this problem is mod_perl. mod_perl, written by Doug MacEachern and distributed under CPAN, embeds the Perl interpreter directly into the web server. The effect is that your CGI scripts are precompiled by the server and executed without forking, thus running much more quickly and efficiently. Furthermore, CGI efficiency is only one facet of mod_perl. Since mod_perl is a complete Apache/Perl hybrid, other benefits to mod_perl include:

11.1. Design of mod_perl

mod_perl is a Perl runtime library linked into the Apache server. With mod_perl, the Perl programmer has access to Apache's C language API through an object-oriented Perl interface. This means that you can write Apache modules and extensions entirely in Perl and embed Perl code and custom directives in your Apache configuration files. Furthermore, the embedded Perl interpreter removes the overhead that you'd experience if you'd merely written a Perl CGI program and put it in Apache's cgi-bin.

Aside from the framework mentioned above, another major benefit of mod_perl is the Apache::Registry module. Apache::Registry implements the CGI environment under the mod_perl framework, which means that you can reuse most of your existing Perl CGI programs to realize the benefits of mod_perl. Apache::Registry caches compiled scripts on the first execution of a script and updates scripts that have changed on disk.

Finally, mod_perl gives the Perl programmer the ability to interact with all stages of an HTTP request, many of which aren't available through CGI. These include the Apache handler phase, the HTTP header parser, URI translation, authentication, authorization, access (permissions), type checking, fixup, and logger stages.

Now that you've been subjected to two rather optimistic paragraphs, we'll take a few moments to appease the cynics. It might occur to you that sticking a large program into another large program makes a very, very large program. mod_perl certainly makes httpd significantly bigger. If you have limited memory capacity, mod_perl may not be for you. There are several ways to minimize the size of Apache with mod_perl (which you can find in the mod_perl manpage or the FAQs), ranging from fiddling with Apache configuration directives to building Perl with reduced memory consumption.

Chapter 11. Web Server Programming with mod_perl

Contents:

11.1. Design of mod_perl