By hook, and by crook and mysterious paths, we made a Catalyst app utilise mod_perl2 on Sarge today. It is very easy, just don't do it the way we did, and spend half a day on it.

Okay - the goal, is that having written a Catalyst app the boss wants it to run in less than the 3 seconds for a page load that it takes as a CGI (on our archaic test box). I want to run it in a maintainable version of Debian (read Sarge), without too many "hacks", I'd prefer to use the Sarge mod_perl2 if possible, because we want Apache2 to be reliable as well as fast, so it is better if the "apps" come to the "server", rather than bastardising the server config for one application.

Catalyst was installed from CPAN, probably a bad move, but it is a hell of a big chunk of packages, and dependencies to repackage for Sarge. I'm still thinking about whether it should be packaged for Sarge before we go live.

mod_perl2 is installed from Sarge libapache2-mod-perl2 (don't forget "a2enmod perl").

Apache2 is the mpm-prefork version because we already had the PHP module installed, and the Debian Apache2 PHP module take Zends warnings about threading far too seriously.

The "Catalyst" apps just needs a "%lt;perl>\n use lib '/approot/lib' \n</perl>" entry, so that Apache2 knows where to find the module it needs as a handler.

Then a location is created in a virtual server that runs the Catalyst application directly from the lib above.

<location /locationtorun/app>
SetHandler perl-script
PerlHandler app-mod-name
Options ExecCGI -MultiViews
Order allow,deny
Allow from all
</location>

Enabling the debugging in Catalyst means that the Apache2 error log will be extremely instructive if things go wrong, and will also tell you how much time is consumed in generating the pages, so you can tell if mod_perl2 does its magic.

At this point we hit a bug. Catalyst::Engine::Apache2::MP19 refers to Apache::Const::OK, when the documentation on the Apache2 rename is quite clear that in mod_perl before 1.999.22 (Debian Sarge stopped at 1.999.21 because of this rename) this constant should be "Apache::OK". This seems to be a "cut and paste" error, but it seems odd, and I can't help thinking someone else must have made it work when they wrote the code to select MP19 as the engine. Anyway we fixed this one constant declaration and we were away.

http://perl.apache.org/docs/2.0/rename.html


Our mistake was to believe it couldn't be done in Sarge, and so to install libraries from CPAN including mod_perl2 first. The Perl modules go in "/usr/local/lib/perl" and "/usr/local/share/perl" when they come from CPAN, but getting the CPAN versions nicely consistent with Apache2 in Sarge, was beginning to drive me mad. Then of course when we backed out to Sarge's mod_perl2 we hit issues with the "/usr/local" versions being picked up in @INC before some of the relevant Debian perl packages. Requiring a couple of "mv package package.old" (the basic "cpan" lacks an uninstall, and a "deborphan" equivalent).

mod_perl2 also broke the "FindBin" module, but this is well understood.

See "%inc" section in;
http://perl.apache.org/docs/general/perl_reference/perl_reference.html

The outcome was our pages render many times quicker. Apache processes seem to use about 8MB more memory after they have first loaded this relatively small Catalyst application.

Of course we need some testing, and then to recreate this environment on the live server, but it is looking pretty solid so far.