Is mod_perl what I'm looking for? FastCGI? PSGI/Plack?

Question

I have exhausted my ability to find answers on the web for this one. I'm trying to install mod_perl on windows and there are many dead ends.

1. Is mod_perl even what I'm looking for?***

   I have a collection of web apps used within my company's local network for database and file system interface. The web server runs Apache 2.2 and ActivePerl 5.16 using DBI, DBD::mysql, and CGI. The clients get their dynamic content via AJAX calls (jQuery.getJSON) to the Perl scripts using CGI parameters. The traffic is extremely light - only 4 or so users and only a few queries at a time here and there.

   The issue I'm having is that the latency is unacceptable for the nature of these apps. The delay is typically around 400ms, all waiting time. I have experimented with increasingly simplistic Perl scripts and believe all of the delay is the Perl interpreter. I've looked into FastCGI but as I understand this deals mostly with high traffic which is not my problem: it's the overhead of each low-traffic call. So it seems like an Apache-embedded Perl interpreter (as I understand mod_perl to be) would solve my overhead-related latency issues.

2. How do you install it in a post Randy Kobes world?

   All resources I've found for installing mod_perl for my setup involve a server theory5x.uwinnipeg.ca formerly run by him and now defunct after his passing. ActivePerl ppm does not have any mod_perl built in packages and the website shows all build failed listings.

Here is an ActiveState community post explaining why there is no ppm.

I did find this resource that seems to have all the missing pieces but for Strawberry Perl.

So I'm left to think the only way to do this is to install from source, but I have no understanding of how to do this. I have zero familiarity with Linux and it seems like most of this stuff is geared toward it. Worse yet I have a 64-bit Windows XP and a Windows Server to install it on.

The other thing that crossed my mind is maybe I need to install some kind of distribution like XAMPP instead of putting together all the pieces myself. I'd be quite nervous to change course now and risk breaking my working but slow apps

Answer 1

It's been an eternity since I've installed mod_perl on Windows so I'm not sure I can help you with that.

But your understanding that FastCGI "deals mostly with high traffic" is not correct. Both FastCGI and mod_perl will offer very similar performance benefits, because both will execute your scripts with a persistent interpreter–eliminating the overhead of starting up perl and compiling your code on each request. Therefore, there is no reason not to give FastCGI a shot.

You might want to look at the PSGI/Plack API which allows you to write code agnostically that can run under vanilla CGI, FastCGI, mod_perl, or with a PSGI-aware server such as Starman, or uwsgi. All of these except for vanilla CGI offer a persistent environment that will reduce the overhead of executing your scripts.

Answer 2

Is mod_perl even what I'm looking for?

I hope not.

There are issues with mod_perl. Your Apache, mod_perl and perl need to all be built with compatible compilers and architectures so they can all be linked at run time. There will be no running of a 32bit Apache with a 64bit perl when you are using mod_perl. In my experience mod_perl should also be compiled against header files for your specific versions of both Apache and perl. Presuming you get all this secret sauce mixed up correctly, you are now running a web server that can be crashed by a poorly written perl script. But on the bright side, this is more efficient than common CGI.

After a few years of this madness, FastCGI was invented. By running as a persistent, but separate, process, the web server was able to achieve mod_perl (or mod_PHP, or mod_python) efficiency without the need for binary compatibility or the stability risks. Just think of the freedom! An Apache module that cares only about binary compatability with it's Apache host and can farm out tasks to Perl, Python, C or even Visual Basic. ( I just had an evil thought about trying to do web services with Forth or Lisp, but that would just be crazy.)

Running on a linux distro (or other canned XAMPP stack) can make setup and maintenance of mod_perl easier because they will distribute it in a package that has been compiled to work with the packages they supply of both Apache & perl. Unfortunately if you want to run with a version of Apache or perl that is not "official" to your distro, get ready to DIY. Even so, a distro's packages do not mitigate the stability issues inherent in running mod_(language-of-choice).

---

In any case, before you're up and running in your new configuration, your existing CGI scripts will need to be modified. You can choose to rewrite them to mod_perl, FastCGI, or PSGI/Plack standards. If you choose to rewrite to PSGI/Plack standards, then you can care much less about the specifics of your web server's current or future configuration.

How do you install it in a post Randy Kobes world?

The last link in your question appears to be spot on. Do you have a religious or PHB based reason to prefer ActivePerl over StrawberryPerl? In the end, mod_perl requires that it be built against your specific version of Apache and your specific version of perl. This will either involve compiling it yourself, somebody else wrapping up versions for multiple Apache/perl version combos, or somebody else wrapping up a single version and asking you to use their preferred versions of Apache & perl.

If you choose the mod_perl route and believe even slightly that server software should be kept up to date (XP? Seriously?), then be prepared to either roll your own or trust your 3rd party to keep you up to date. Of course, if you're a hit-and-run developer, well that frees up your choices considerably...

---

tl-dr:

FastCGI is your friend. Particularly if you are running Windows and like to keep server software up to date.

mod_perl works best when supported by a responsible distro or a responsible developer who is comfortable building it from it's source. ...repeatedly.