in reply to prevelance of mod_perl

Unless your application is specifically written to work under CGI as well as mod_perl, it will not work to use CGI. It would also be much slower, as you say.

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.

Replies are listed 'Best First'.
Re^2: prevelance of mod_perl
by cutlass2006 (Pilgrim) on Jun 04, 2008 at 13:29 UTC

    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.

[reply]
      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.
[reply]
        I was actually under the impression that mod_perl wouldn't ever be safe for shared hosting until something like the perchild MPM was finished. Did this change recently?
[reply]

In Section Seekers of Perl Wisdom