Re: Fast CGI or mod

We now use mod_perl on our company's system, but for awhile (few years) we ran FastCGI. I love FastCGI. Static pages remain entirely static, without the overhead of calls to mod_perl hooks and without the memory bloat in each process caused by mod_perl (though much of the extra memory is shared).

FastCGI, if used correctly, allows for some fine tuning of your server. You can say, please dedicate 40 processes to this cgi, 2 processes to that cgi, etc. I would imagine, just from the layout of FastCGI, that it would run more quickly and take less memory thay mod_perl Apache::PerlRun. The latter has to go through it's hooks, share all loaded modules with anything else that is going to run (still require new modules if necessary), do the hit, and then tear down the package space when it is done. The FastCGI stays inside the isolated CGI and simply loops on connections. No tear down process, no other hooks, no shared modules are necessary.

That all said, mod_perl does handle a lot for you and you don't have to worry about fine tuning your webserver as everything is handled by an already running perl.

my @a=qw(random brilliant braindead); print $a[rand(@a)];

Comment on Re: Fast CGI or mod_perl

Replies are listed 'Best First'.
Re: Re: Fast CGI or mod_perl by perrin (Chancellor) on Dec 08, 2001 at 04:14 UTC
Nothing personal, but I think some of your statements here aren't quite accurate and I don't want people to get the wrong idea about mod_perl/FastCGI. FastCGI, if used correctly, allows for some fine tuning of your server. You can say, please dedicate 40 processes to this cgi, 2 processes to that cgi, etc. That would save you some memory, but it would be a lot of work to determine the optimimum use of resources and you'd have to monitor and change it continuously as the popularity of various items on your site waxes and wanes. Technically you could do this with mod_perl if you're using a front-end proxy setup, with a different mod_perl server for each script or group of scripts. Probably only worth it under very special circumstances though. I would imagine, just from the layout of FastCGI, that it would run more quickly and take less memory thay mod_perl Apache::PerlRun. Less memory, maybe. Probably not better performance than Apache::Registry. The latter has to go through it's hooks They can be disabled if you don't need them. share all loaded modules with anything else that is going to run (still require new modules if necessary) You should normally pre-load your modules with mod_perl, but yes, all modules needed for all the scripts you run under mod_perl are typically loaded into the same server. do the hit, and then tear down the package space when it is done. Note that only PerlRun does this, and it's to protect you from any bad things you may have done with globals. If you use Apache::Registry, it does no more "tear down" than FastCGI does. Also, consider that FastCGI adds overhead in the form of a socket call and communication to the external FastCGI process. If you run mod_perl with a front-end proxy, you take a similar hit there.	[reply]
Re: Re: Fast CGI or mod_perl by ask (Pilgrim) on Dec 08, 2001 at 05:36 UTC
static pages can remain entirely static in a mod_perl setup too. With mod_perl you can also allocate X processes for an application. It's all about setting it up right. :-) http://develooper.com/modperl/ - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();	[reply]