MySQL and Perl for the Web: Chapter 3 Section 2 (4/5)

[previous][next]

Improving Performance with mod_perl

Set Up a mod_perl Startup File

The Apache::Registry handler automatically sets up the CGI environment for your Perl scripts. You can augment the information that Apache::Registry provides by setting up a mod_perl startup file to be read during Apache's initialization process. (The file is written in Perl, of course.) To do this, use a PerlRequire directive. If you want to call the file startup.pl and put it with the other Apache configuration files in the conf directory under the server root, for instance, add this line to httpd.conf:

PerlRequire conf/startup.pl

If you want to put the startup file in lib/perl with the other Perl library files, use this line instead:

PerlRequire lib/perl/startup.pl

After configuring httpd.conf to specify the location of the startup file, what should you put in it? That's up to you. One way to use the file is to set up additional information in the standard environment under which you want your scripts to run. If many of your scripts include a use lib pathname line to add a given directory to the Perl search path, you can add the directory to the path in the startup file instead. Then it's added automatically, and your scripts don't need to do it for themselves.

Another use for the startup file is to preload common Perl modules to improve performance. When Apache starts up, it reads and processes its configuration file (which includes processing the mod_perl startup file). Then it spawns a bunch of child httpd processes to handle client requests. In general, the more work you can get done in the parent httpd process before it starts spawning children, the more efficient your system will be. This is true not only for script execution speed, but also for system resource consumption, particularly memory use. Let's see why this is.

Each child httpd begins executing as a copy of the parent, and, due to the way virtual memory works, it shares the address space of the parent rather than doubling the amount of memory used. As the processes run, the amount of shared address space tends to decrease. (If the child changes a data structure, for instance, any memory pages containing that data can no longer be shared with the parent. The system duplicates those pages and marks them as unshared--unique to and owned by the child.) Nevertheless, a large amount of address space generally continues to be shared between the parent and its children; this is a big win for memory management and for system performance in general.

You can use the mod_perl startup file to influence your system's performance by exploiting the address space sharing provided by virtual memory. If you tend to use certain Perl modules in many of your scripts, you can name them in the startup file to preload them into the parent httpd process. The code of these modules then becomes part of that process and thus part of its address space that can be shared with the child processes. The parent process becomes larger, but overall memory use goes down, compared to having those modules loaded by each individual child and becoming part of their unshared address space.

An additional benefit of code preloading is that the code is compiled only once, by the parent. The children receive the code precompiled. Any module that isn't preloaded must be loaded and compiled by each child individually when scripts run by the child request it, so more processor time is used.

[previous][next]