Hang onto your hats again. Consider this fair warning ... don't way I didn't warn ya ... all that good stuff. As I move into mod_perl, you should know that this is going to be one of those sections like the one in which I started breaking things into modules; one that I enter doing things in one way and exit doing things in a wholly different manner. Kinda fun, huh?

Before I get into this, I think it appropriate to note that more and more as I go on, the step ahead is not necessarily more correct, nor even inherently more sophisticated, than what has come previously. One might argue that they will be more fine-tuned to a given context, but recognize that fine-tuning can entail trade-offs. A couple of years ago I put together a quick browser page that was used to generate queries against a database and summarize the results. It provided a capability for the user that had not before existed. I could have wrapped it up into one big cgi and ultimately migrated it to mod_perl, but there was really no point. It was a real and significant tool, but it was used perhaps twice a week by one person. The aggregate impact of the performance increases I could have induced might have saved that user 30-45 seconds per week. Would it have made sense for me to invest a day doing that? (That's a rhetorical question, btw. You don't need to e-mail the answer to me.)

I am not going to write a detailed section about the installation of mod_perl ... if you want to build the package from source or investigate the default location of mod_perl files after building from source, you couldn't find a better source of information than this. I will probably get into some level of detail regarding that in a later section. I am going forward on the basis of the debian woody binary of version 1.3 of mod_perl. To get that done, simply type "apt-get apache-perl", and as long as the configuration of apt is still appropriate (you haven't changed anything, have you?) the requisite files will be installed.

Before I get into this more deeply, however, I should probably devote a little time to terminology. Generally, mod_perl is used to describe the version of apache with a copy of the perl interpreter embedded within it. "Specialty" configurations of apache are frequently characterized with the preface "mod_" followed by a term describing the customization. This stems from the names of the C-language libraries that are compiled into the executable when a modification is incorporated. I have, for example, seen the relatively generic apache installation configured to support cgi scripts described as mod_cgi, and an installation embedding the interpreter for the php scripting language as mod_php. There are lots of mods, including mod_ssl, which includes support for secure socket layers. It is likely that any given installation of apache supporting even a moderately powered web host is modded (modified) to support several interfaces. Each one that is included, however, adds to the memory and other system resources required to support the server, which can affect the performance of the server. If one is running a web hosting company one is likely to make the investment in the hardware required to support that, because the number of services available is an important determinant of how many clients that company is likely to have. Alternatively, if apache is being configured as, in effect, an application server to support a well-defined set of application(s), there is no point in making the server software any larger than is required to support that set, especially when optimization of the performance of a given set of hardware is a concern. The "apache-perl" referenced above is simply the name for the debian apache binary package incorporating support for mod_perl, and is purely a debian convention.

All of this is leading in a direction that is a little bit beyond where I am right now. Let's just get into messing around, because that's the best way to pick up on how all this hangs together. I will start off in the next section by doing a basic installation of mod_perl, and then make the changes required to run the current script under the arache perl module that in effect creates the emulation environment that allows cgi scripts to be executed under mod_perl, providing a noticeable performance boost without requiring substantial recoding. In later sections I will launch into restructuring the script into the form preferred by mod_perl.