mod_perl is this new(er) scripting technology based on perl and apache. The idea is simple and VERY effective - embed a perl interpreter directly into the webserver, write some code to maintain and cache "compiled" scripts, and wham - really freaking fast scripts. It rocks!

mod_perl puts a Perl interpreter right inside the Apache Web server, so there's no wind-up time for any scripts, which stay compiled between hits. For a site which uses a lot of scripting, especially when tied into a database, upgrading to mod_perl can be a life-saver.

It takes a bit of work to get CGI scripts running properly with mod_perl, but it is a lot easier than using FastCGI, re-writing everything in C, or buying more servers. If you're already using "strict", then the changes you have to make are pretty minor. If your code is wild and wily, a good house-cleaning effort is advised. The only reason is because global variables stay initialized between Web hits, which can have the interesting effect of adding your items to someone else's shopping cart, for example, because the shopping cart structure wasn't initialized for each "hit".

mod_perl like methamphetamines for your server, only without the nasty coming down part.

mod_perl also exposes the 'request', 'server', and 'connection' objects for use in perl programs. these are the same structs (or close, anyway...) used in apache itself, and are *sweet*.

apache as a) application framework and b) a pre-fab, object/file/meta broker. no. you're right, it's not corba, it's a dessert-topping/floorwax!

With mod_perl it is possible to write Apache modules entirely in Perl. In addition, the persistent interpreter embedded in the server avoids the overhead of starting an external interpreter and the penalty of Perl start-up time. As usual O'Reilly has a book Writing Apache Modules with Perl and C ( that may help.

See also PerlScript for Windows based web server.


As someone who has recently discovered the sweet creamy goodness of mod_perl, I would like to pass along some wisdom that I learned during my self-teaching crash-course. I am just another below-average Perl Hacker, so take all advice with a (large) grain of salt:

  • Use 'use strict;' - I cannot express that enough. I'll say it again; use strict;. Too many people think that it is really an optional thing and, in regular perl programs, it might be; but in the mod_perl world you have three options: 'use strict;' (thereby forcing you to declare variables with the 'my' operator to limit scope), make sure you explicitly define your variables' values before they are evaluated (i.e. "$scalar = '';") or undefine everything at the end (i.e. "undef $scalar;"). Which do you think will be easier?

    The reason here, as was already stated above, is that mod_perl keeps a compiled copy of the script in memory, along with any variable values (unless they have gone out of scope or have been undefined). However, there may be one or two times you *want* a variable to be persistent -- the first thing that comes to mind is a database handle. If it persists across multiple executes, you won't have the overhead of re-initializing the database connection every time.

  • Restart Apache when you make a change - Because a compiled copy of your script is kept in memory, if you make a change to the source, the change won't immediately be available as with traditional CGIs. To flush the compiled scripts from memory, the easiest way I've learned is to simple restart the 'httpd' daemon. And the easiest way to do this is is "/path/to/apache/bin/apachectl restart".

  • Optimize your Code - Sure, using mod-perl is fast, but it won't make up for sloppy, inefficient code. Clean things up, don't make nth-iteration loops if you don't have to.

  • Get more memory - Since a lot of stuff will get stuffed into RAM, you'll need more memory then is traditionally needed, especially if you have multiple scripts being executed concurrently. It can devour core faster than Delta Burke chows Snackwells. I thought I could get decent performance using 32 megabytes of RAM... I was so wrong.

  • Remeber that page headers can he handled for you - Output from a perl program being run though mod_perl will automagically be prefixed with the appropriate header. That means if you're like me an used to use 'print "Content-type: text/html\n\n";' to do headers, it will actulally display that line at the top of the outputted page.

    The way to overcome this is (my personal opinion) to use the perl CGI module to create your headers:

    my $query = new CGI;
    print $query->header ();

    The CGI module talks to mod_perl so if only one of the two entities involved prints the line so you don't get duplicates. Additionally, if you need a header for a differnet MIME type, use something like:

    print $query->header ('text/x-hdml');

    ...and that will cause mod_perl and Apache to send an HDML header verses an HTML header.

Additional (5/2/01): There is another nasty problemn with mod_perl that I think you all need to be aware ofef -- the neffarious 'require' problem, otherwise known long-windedly as 'my code only runs the first time, then dies!' problem.

This happens because mod_perl is trying to save time, and therefor will only process 'require' statements once (unless %INC is modifed). The problem here is that if you did not define a package in your require'd file, you will not be able to access those subs the next time it is run, and it will die with an 'unable to locate method' error in the Apache Log.

Another side of nastiness here I recently learned all about is if two require'd codeblocks possess the same package name but have different contents and are being called in two differnt programs they will still share address space anyway, and it will still only be loaded once. So when the second program tries to access methods not in the first programs' require'd codeblock, it will also die with the usual error. I've been trying some workarounds about this, and saddly the only one that seems feasable is to make sure to not have require'd packages possess the same name petween different entitites (programs).

Log in or register to write something here or to contact authors.