8.1 Introduction

mod_perl is another, better way to create dynamic web pages. It is faster and far more flexible than CGI and has the advantage of being based on Perl. Thus it provides the dual benefit of building on the knowledge base you've gained by studying Perl, and taking advantage of the entire Perl base.

mod_perl is a fully functional Perl interpreter embedded in the Apache webserver , making the Perl interpreter always available for CGI programs ”there is no extra step to load Perl into memory. Also, mod_perl is smart enough to cache CGI programs in memory, so if a CGI program is run multiple times, it is compiled only once. The result is a considerable improvement in speed.

Speed is not the only advantage of mod_perl. It also gives you increased power, flexibility, and the ability to customize Apache. Because Perl is built into Apache, Perl is available to the server at all times. So you can write Perl code that performs customized processing during any phase of Apache's processing, from the request phase to the authentication phase to the logging phase (to name just a few).

Another feature of mod_perl is that with the Apache::Registry module, you can instantly turn your existing CGI programs into mod_perl programs. Your existing CGI programs will run considerably faster, with no rewriting.

You can also write pure mod_perl programs ("pure" meaning using the mod_perl API instead of the CGI.pm module). These programs generally run faster than CGI programs because they use the native mod_perl API instead of a module.

8.1.1 How It's Faster

Figure 8.1 depicts what happens when a CGI program is executed, as explained in Chapter 7. When the request is made for the CGI program, a.cgi , the httpd child process that is handling the request discovers that the CGI program is to be executed by Perl (it learns this from the first line of a.cgi : #!/usr/bin/perl ). Therefore, the child process first loads perl into memory (this takes some work and time to do). Then, the perl process executes a.cgi by first compiling it into an internal byte-code representation (this compilation takes some work and time to do) and then executing it.

Figure 8.1. CGI execution

If a.cgi is executed multiple times a day (let's say a million, for a nice round number), this loading of Perl/compilation/execution must be repeated a million times a day. This is inefficient. Instead, wouldn't it be nice to be able to eliminate the first two steps by loading Perl only once and compiling a.cgi only once, leaving only the execution of a.cgi ? If this could be done, the execution of a.cgi could be sped up significantly. mod_perl can do this!

When you want to use mod_perl to execute a.cgi , the scenario looks like Figure 8.2. With mod_perl, the httpd child process has Perl embedded within it, so there is no need to load Perl when a.cgi is to be executed, thereby eliminating the need for the first step of the load/compile/execute process. The first time a.cgi is requested by the child process, the process compiles it and then caches it within itself so that subsequent executions of a.cgi are like executing a function. Thus a.cgi does not need to be compiled again for that child process (eliminating the need for the second step of the load/compile/execute process). When a.cgi is requested, it is simply executed. Quite zippy!

Figure 8.2. Execution of mod_perl