start page | rating of books | rating of authors | reviews | copyrights

Book HomeWebmaster in a Nutshell, 3rd EditionSearch this book

15.4. Running CGI Scripts with mod_perl

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 CGI scripts repeatedly spawning 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 come to a crawl.

Withmod_perl and Apache::Registry, however, your CGI scripts are precompiled by the server and executed without forking, thus running much more quickly and efficiently.

The mod_perl installation enables the PerlHandler callback hook by default and by installing the Apache::Registry module. PerlHandler is the handler used for the content retrieval stage of the server transaction. Apache::Registry is the Perl module that emulates the CGI environment so you can use "standard" Perl CGI scripts with mod_perl without having to rewrite them (much). This is by far the cheapest way to get improved CGI performance.

With Apache::Registry, each individual CGI program is compiled and cached the first time it is called (or whenever it is changed) and remains available for all subsequent instances of that CGI script. This process avoids the costs of startup time.

Whereas most CGI scripts are kept in /cgi-bin/, scripts that use Apache::Registry are placed in a separate directory, e.g., /perl-bin/. The access.conf Apache configuration file needs to point to this directory by setting an alias and defining a handler for this new location:

Alias /perl-bin/ /usr/local/apache/perl-bin/

<Location /perl-bin>
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Options ExecCGI
</Location>

Instead of the cgi-script handler, use the perl-script handler to give control to mod_perl. Next, the PerlHandler directive tells mod_perl that the Apache::Registry module should be used for serving all files in that directory. PerlSendHeader is another mod_perl-specific directive; in this case, it tells mod_perl to send response lines and common headers; by default, none are sent. (For NPH scripts, you'll want to turn this feature off again.) Options ExecCGI is a standard Apache header needed to tell Apache to treat the script as a CGI script.

If you want to load Perl modules in addition to Apache::Registry, use the PerlModule directive:

PerlModule CGI

If you include this line, you shouldn't need to explicitly use CGI in each Perl CGI script anymore, as CGI.pm is loaded directly from the Apache server. Up to 10 modules can be listed with the PerlModule directive.

CGI scripts in the new directory should work now. However, if you have problems, the mod_perl manpage offers some words of wisdom:

Always use strict
"Standard" CGI scripts start with a clean slate every time. When switching to mod_perl, CGI programmers are often surprised to learn how often they take advantage of this fact. use strict tells you when your variables haven't been properly declared and might inherit values from previous invocations of the script.

Don't call exit( )
Calling exit( ) at the end of every program is a habit of many programmers. While often totally unnecessary, it usually doesn't hurt . . . except with mod_perl. If you're using mod_perl without Apache::Registry, exit( ) kills the server process. If exit( ) is the last function call, just remove it. If the structure of your program is such that it is called from the middle of the script, you can put a label at the end of the script and use goto( ). There's also an Apache->exit( ) call you can use if you're really attached to exit( ). If you're using Apache::Registry, you don't have to worry about this problem. Apache::Registry is smart enough to override all exit( ) calls with Apache->exit( ).

In addition, you should use recent versions of Perl and CGI.pm. You can scan the mod_perl documentation for the very latest compatibility news.



Library Navigation Links

Copyright © 2003 O'Reilly & Associates. All rights reserved.