Transitioning to mod_perl

[jeyroz]

After working in a CGI environment on countless projects I’m interested in transitioning our future work to mod_perl. I’ve read that mod_perl can be a bit risky in the wrong hands especially in a shared server environment, as our servers are.

I’m hoping to get a little insight from my fellow monks regarding their (your) experiences … horror stories, pit falls, cautionary tales, etc. This is of course, not to discount any positive reports. I’m also interested in hearing about the pros and/or cons of mod_perl from practicing users/developers.

As always, thank you all for your advice and suggestions.

[erix]

Practical mod_perl

Be aware that it is almost entirely about mod_perl 1.

[cbrandtbuffalo]

As you transition, you'll also probably need to do some work in your development environment. In our experience, each developer needs their own dev server because as you're working and changing things, you need to restart the server often. You also want to work on a personal server with just one child so you don't drive yourself crazy when different code gets loaded into different children.

This happens because when you're using Apache::Registry, your code is loaded into memory when an apache child responds to a request. As you're developing, you change things often, and if you forget to restart your server, the old code can still be in memory. I find this can happen especially for people used to a CGI environment.

For us, setting up an environment to have personal server required some work. We finally landed on a system that uses a shared apache binary, but allows developers to have their own config file, logs, etc.

[sharkey]

I haven't had any serious difficulties with mod_perl, but I do not use Apache::Registry or the like. If you do mod_perl, I would highly recommend one of the popular templating systems, like Mason or Template::whichever.

The general rules to avoid problems are:

use strict;
use warnings;
(no warnings 'uninitialized' may be convenient if you deal with a lot of nulls from a database.)

Keep global variables to a few obvious necessities, like $dbh and $session. These should be initialized by your templating system or your handler function, before your page logic even gets a chance to run.

[jeyroz]

We currently use CGI::Application, HTML::Template, Apache::Session, and others. Strict is mandatory, as is warnings. We have a rigid QA and "post test" cleanup schedule that keeps our code as clean as possible.

Hopefully that will be sufficient for the time being.

[chrism01]

Well, apart from the usual rules ie use
perl -w

and

use strict;

the thing I've had to fix a few times on old code is ensuring that all variables are initialised each time they are used.
Remember that the scripts are cached in mem by Apache, as are the last values the variables had...

[kiat]

A clarification...

Does that mean that if your scripts run without problems with "use strict;", they will do fine with mod_perl?

[Anonymous Monk]

No, that's just the 1st step.

[Anonymous Monk]

Visit the mod perl website, search the lists, get the book

[doink123]

Shared server environment? You mean virtual hosts? mod_perl has problems with virtual hosts, because Apache/2 has limitations. For apache 1.x these limitations are there forever but for Apache 2.x I think (and hope) they soon will be gone.
The problem with mod_perl and the virtual hosts is the security. Currently Apache 2 has a solution and it's called Perchild MPM, but it's broken and development has stalled. My hope is that it will be fixed soon, because Google's summer code is starting and there is a guy volunteering to fix the Perchild MPM in three months.
There is an alternative to perchild - Mutex MPM. It's in beta, works good most of the time, but has some issues and development has stalled here too.
Another alternative to perchild is the Peruser MPM. Seems like the developers are working on it, but thats all I know.