Improving Performance with mod_perl

These benefits do come at a price, of course. There are also some disadvantages to using mod_perl:

• Apache installation and configuration becomes more involved.

• The script-execution environment persists across scripts. (Yes, I included this in the preceding list of advantages, but persistence of the Perl interpreter's internal state also can cause problems if a script is a bad citizen that contaminates the environment of its successors.) Such scripts require some tweaking to behave better.

• Embedding the Perl interpreter into Apache causes httpd processes to become larger and take more memory. You may find it prudent or necessary to perform some configuration tuning.

• mod_perl scripts always run under the user and group IDs of the httpd process. You can't execute them with the privileges of another user or group using the suEXEC mechanism the way you can with standalone scripts.

I've listed more disadvantages than advantages, which you may find alarming. However, most of the disadvantages are one-time issues. Apache configuration is more complicated with mod_perl, but after you get things set up the way you want them, you usually can leave your configuration alone. A script that needs some modification to run as a good citizen under mod_perl generally needs to be fixed once, not multiple times.

The benefits, on the other hand, are continuous. Having scripts run faster with mod_perl than when executed as standalone programs is a benefit you enjoy for as long as you continue to use Apache. The amount of improvement varies from site to site, but the mod_perl Guide indicates that developers report scripts running anywhere from 2 to 20 times faster than the equivalent standalone versions. See Appendix B for other reports of user experiences.