Perl in shared hosting environments
djk at tobit.co.uk
Wed Sep 21 17:16:05 BST 2011
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).
More information about the london.pm