Perl in shared hosting environments

[Dirk Koopman]

On 21/09/11 16:49, Randal L. Schwartz wrote:
>>>>>> "Dirk" == Dirk Koopman<djk at tobit.co.uk>  writes:
>
>
> Dirk>  Reason include:
>
> You forgot:
>
> * My application only requires content generation, and I can completely
>    ignore the other 14 phases of serving, because I don't want custom
>    redirects, authentication, authorization, mime interpretation, and/or
>    logging and other things written in the language of my choice: Perl.
>
> Seriously... *nothing* can compete with mod_perl as far as its reach
> into Apache.  *Nothing*.  With mod_perl, you can inject new behavior at
> every level of decision making that Apache does.  FastCGI is replacing
> just *one* of those 14 stages.
>

And these are advantages or reasons to avoid mod_perl? I agree with your 
last paragraph, but I have to utter a very politely meant, but 
heartfelt, "so what".

Nothing written, so far, would cause me to stop avoiding Apache with 
every fibre of my being. It is a hateful security_hole^Hprogram and 
mod_perl is an unfortunate part of that.

Also once perl is embedded into any thing and one uses perl extensively 
within, the speed of the thing will tend toward the speed of the perl part.

In the case of a (web)server, these days, one may as well use one of the 
perl (web)server modules/frameworks and do the whole lot in perl. Maybe 
using some of the newer XS support modules.

All stages of a request are available. It isn't significantly slower 
than mod_perl (and maybe quicker). The memory requirements seem to 
stabilise very quickly and are reasonable. I have perl servers of one 
kind or another that stay up for years at a time even under some 
aggressive attempts to DoS / exceed limits. The joy of "infinite" buffer 
sizes and garbage collection. And it's easier to debug (although it 
would be nice not to have Carp::Heavy crash on errors quite so frequently).

Dirk