There exist a few options to handle Perl CGI and such... I removed all
traces of Apache from 3 machines...

fcgiwrap


Jonathan Vanasco wrote:
> If you are truly committed to running Perl...
>
> your best option would be this:
>
> Port 80 : Nginx serves static and proxies to Perl system
> Port 80xx : Perl system ; either apache+fcgi or apache+mod_perl ...
> you might be able to run things under perlbal via plugins, but i dunno.
>
> The ideal situation would be running fcgi under nginx, but I found it
> a PITA to set up / maintain.
>
> I caved in and ran some perl apps through apache+mod_fcgi , and its
> pretty nice. Nginx handles most of the requests itself, so 2 apache
> children are handling a decent amount of traffic.
>
> I have a few production projects running nginx on 80 and proxying back
> to mod_perl enabled apache. They work great, but they're apps
> designed to utilize a bunch of MP + Apache2 features... nginx was
> brought in a few years ago to increase improvement... and it was
> miraculous: nginx does awesome queuing/handoff of the mp traffic, so
> all apache does is process mod_perl fast and instantly. no lazy
> client issues, no wasting resources on bloated servers.
>
> in practice.. i haven't found /that/ much difference between a
> fine-tuned Apache+ModPerl , PHP ( via apache+mod_php or fcgi ) ,
> Python ( django / pylons ) setup. Sure you can have a system where
> php+fcgi is taking up 50MB of ram while Apache+ModPerl is taking up
> 150... but to tweak the performance to equal one another you'd use a
> PHP cache that takes up 135MB of ram... making everything pretty darn
> negligble.
>