• How prevalent is mod_perl?
  • It's quite prevalent. According to Netcraft, it is being used on approximately 4 million hostnames.
• Is mod_perl outdated, replaced by something newer??
  • No. It is the state-of-the-art when it comes to writing the most scalable web sites backed by Perl.
• But all those (other Perl modules) and why not mod_perl? WHY?, WHY?
  • As opposed to other modules, mod_perl must be compiled into Apache. That is, when you compile Apache, you point the compiler at both the Apache source and mod_perl source, and it builds the Apache executable with mod_perl together. If Apache has been built without mod_perl, you can't simply type perl -MCPAN -e 'install mod_perl'; rather, you have to recompile Apache.
  • In that sense, it's installed and used in a completely different way than other Perl modules.
• Is it that not many programs use it and it is a hassle to admin on their Apache servers? Or does it create conflicts, Or?, Or?
  • No. There are lots of products that use mod_perl. I can even think of some widely used ones that aren't on the list ... I believe TWiki is mod_perl-compatible.
  • However, the generic hosting companies are marketing to the lowest common denominator. That is, they limit themselves to the most widely used products and/or less sophisticated users.
    • mod_perl is widely used, but is not as widely used as PHP, which is run on about 10 times as many IPs.
    • mod_perl requires a bit more sophistication than CGI. It's not a big leap, but you have to be aware of such things as how global variables can be shared across processes and use strict religiously.
  • So my recommendation would be not to go with a hosting company that is the biggest game in town, as they are marketing to the lowest common denominator, but to look for hosting that is more closely tailored to your needs. As a side benefit, you might also find the smaller shops to actually be more responsive to your needs; e.g., they might give you more than the generic one-line brush-off.
  • In own experience, I use a small shop in Denver called E Street, and I would unreservedly recommend them in a heartbeat. They are so much more responsive than the Rackspace-types in a way that lets me know they read my e-mail and gave it some thought before replying. I've seldom been as happy with a vendor, any vendor, as I have with these guys.

Their stance is not unusual for shared hosting providers. To use the best, fastest setups for Perl, PHP, Ruby, etc. you really need a machine that you control, with root access. The cheapest way to do that these days is usually a virtual server, which can be quite inexpensive.

If you don't want to deal with your own server, you can ask them if they support FastCGI. The application will probably require modification to run under it though if it has only been written for mod_perl.

go figure ... I find it difficult to imagine an ISP which would disallow perl; I guess I live in a completely different tidal pool ;)

That being said, I think trying to force an ISP or inhouse department to support something they naturally do not want to might be asking for trouble ... its your money, just go for a different hosting company

I would recommend trying out www.slicehost.com ... u have a choice of OS, root control and can ramp things up if u need too. Having used Rackspace servers for the past 5 years, I am a bit coddled ... but I am a recent convert to slicehost and can recommend them.

It's not that they disallow Perl, just server modules like mod_perl. Setting up mod_perl to run with the permissions of each individual user is non-trivial most shared-hosting ISPs are not willing to tackle it.

perrin has already mentioned FastCGI, so I'd just like to elaborate a bit on that option, as it might be an alternative to mod_perl, in case your application is essentially written like a regular CGI program, i.e. if it does not rely on specific mod_perl-only features. Performance-wise, FastCGI is comparable to mod_perl, as it's also running your program persistently (thus avoiding the overhead of loading the interpreter, modules, etc. on every request).

The main difference is that with FastCGI separate processes are being forked, which are communicating with the Apache process via sockets (both TCP and unix domain sockets are configurable). Due to this, FastCGI does not have any of mod_perl's powerful facilities to control virtually any aspect of the request cycle and Apache itself. In other words, it's responsible for content generation only — just like regular CGI.

This relative lack of power can be an advantage in this case, however, because mod_perl's power, with all its security implications, is essentially the justification for admins/providers to not support it, in particular in "old-style" shared hosting environments (i.e. those without a dedicated virtual machine for every client).

On the Apache side, you'd need one of the modules mod_fastcgi or mod_fcgi, and on the CGI script side, you can choose between various Perl modules, e.g. CGI::Fast, or FCGI (the latter is pretty old, but I've personally been happy with it so far). You'd use those Perl modules to put a thin wrapper around your CGI program, in order to have it run persistently, and to connect its I/O to the Apache process handling the request.

(In case you have many individual CGI scripts, it's probably a good idea to design things according to the "frontend controller pattern" (as Java/JSF people would say), i.e. one main FCGI process receiving all (or a group of) requests and delegating them to the appropriate handler routines. Otherwise, you may end up with quite a lot of persistently running processes — at least one for every separate CGI program...)

FastCGI may also be configured to work with Apache's suEXEC facilities, which - when done properly - is about as secure as regular CGI can get in a shared hosting environment (with users (ideally) not being able to mess with other user's processes and data).

There are a small select number of dedicated mod_perl hosting providers, however I decided to go with an entire virtual private server (VPS) hosted at Linode in Los Angeles, USA, and then subsequently rented another VPS at ByteMark in London, UK. On the VPSs I can select exactly which Apache version I want to use and add on mod_perl at will.

When I was with IPowerWeb I actually found my CGI Perl pages executed quite quickly, I presume this is because their servers are reasonably powerful even though each one is hosting hundreds of sites.

But of course going with mod_perl gives significant advantages. But there are issues and risks as well:

• threading with mod_perl is a potential issue (and Apache can be run in a per-process mode, or a worker model which initiates lots of threads in each process)
• virtual hosts can cause issues - I've tried running different versions of TWiki on different virtual hosts all using mod_perl on the same Apache server and it has ended in tears

I guess what I'm saying is that if you really want to do mod_perl, then the rewards require that you take some risks, and most standard cheap hosting companies don't want to take those kinds of risks!

The standing advice about mod_perl and threads from the mod_perl community is to not use them if you have a choice. People on Windows have to use them, but on Linux you're better off using the prefork model. It actually uses less memory than the threaded model and avoids problems with CPAN modules that aren't threadsafe.

Regarding the VirtualHost issue you mention, this is a pretty basic limitation of Perl: you can't run two different versions of the same module in one interpreter.

Sites choose to use particular features based on their level of personal comfort and paranoia for the ramifications (usually security-related). Most of what you do with mod_perl you can probably also do with a standard cgi script, in fact I don't think theres really much difference from your perspective, it's just a different handler in the hosted service's apache configuration.

So I would probably ask them how they do stuff with CGI instead of mod_perl, and see if theres any real differences, before you start arguing to have it installed.

The main point of mod_perl is to already have a copy of perl running. This avoids load time for each invocation. Trade-off against vanilla cgi is slight and improvements in response time can be large. It is not a choice of 'cgi' or 'mod_perl', normally you will use both. To quote a quote:

mod_perl is more than CGI scripting on steroids. It is a whole new way to create dynamic content by utilizing the full power of the Apache web server to create stateful sessions, customized user authentication systems, smart proxies and much more. Yet, magically, your old CGI scripts will continue to work and work very fast indeed. With mod_perl you give up nothing and gain so much! http://en.wikipedia.org/wiki/Mod_perl

There are further(many) advanced uses of mod_perl— little of which is particularly down to earth. After all, O'Reilly doesn't publish books about simple things for the most part; but you might toss these on your developer(s) desk(s):
• Practical mod_perl by Stas Beckman and Eric Cholet. O'Reilly<\li>
• Writing Apache Modules with Perl and C by Lincoln Stein and Doug MacEachern. O'Reilly
• mod_perl: Developer's Cookbook by Geoffrey Young, Paul Lindner and Randy Kobes. Sams.

--hsm

"Never try to teach a pig to sing...it wastes your time and it annoys the pig."

Practical mod_perl by Stas Beckman and Eric Cholet. O'Reilly

See also: "mod_perl 2 User's Guide" by Stas Bekman and Jim Brandt (http://modperl2book.org/).

Perlcast recently posted an interview with Stas Bekman and Philippe M. Chiasson on mod_perl back in Jan. A link to the audio can be found on the Perlcast.com page.

• it's a memory hog;
• it's very easy to "corrupt" other processes and scripts running under it;
• it gives access to web server internals;
• buggy perl code can take down a lot more than just the one buggy CGI;
• and so on.

The app is foodclub from foodclub.org It's a food buying club ordering and management system. It's in beta.
It's currently being hosted on the foodclub.org site but we wanted to add features and tie it into an os. shopping cart program. So We set up a project on sourcforge(just setup, no structure at this point) called foodclubcart (orignal, huh?) and put an add on perl.org for help to install it and get it modified.
Several programmer (3 in two weeks) have stepped up, and one is currently working on it but we've hit some snags of installing it and getting it running on the hosted site.
I haven't had a chance to fully digest what you've offered, but I will, thanks

And Thanks all for all of your thought and help so far, it's like wow, I'm used to getting curt answers.
I guess we're all into paying it forward.