If your site never gets posted to Slashdot, and/or you have very few visitors, vanilla CGI is fine. I think FastCGI exists simply because it was invented before mod_perl came to be.

g r i n d e r
just another bofh

Cheers, it seems to me from reading those links that it's got to be mod_perl and fast_cgi is not even a contender anymore.

In a way, mod_perl and mod_cgi are really solving two different problems. mod_cgi takes one file, and maps it to a url, thus doing some crunching then the url gets hit. mod_perl, on the other hand, is a much bigger hammer, and much more closely tied to Apache. People who glance at mod_perl often only see Apache::Registry -- but it's an important point to note that Apache::Registry, while an interesting hack that certainly does allow for CGI-like programs, is really only the tip of the iceberg of what mod_perl can do.

On the gripping hand, the tightness with which mod_perl is bound to Apache can cause no end of troubles -- from bloated httpd processes which slow down serving of static pages, to requiring copious restarts at every niggling change, to segfaults that are nigh-impossible to track down, causing one to spend eons of time, staggering amounts of frustration, and a small amount of hair.

Who me, bitter? ;>

I think mod_cgi will live on for a long time in the realm of short hacks that do only a short list of things, then are done with it. Anything more complicated, like the Everything system that Perlmonks uses, is probably better off with the tight httpd integration of mod_perl.

perl -pe '"I lo*`+$^X$\"$]!$/"=~m%(.*)%s;$_=$1;y^`+*^e v^#$&V"+@( NO CARRIER'

Vanilla CGI is useful in a shared environment, where many users sharing the same instance of Apache aren't allowed to restart the web server, and where the users are more concerned about ease of use than speed. (Anyone who has debugged a mod_perl script for far too long before realizing they just didn't restart apache will know what I'm talking about. "Doh! It works better when you plug it in.")

There are also security issues with running mod_perl on a shared server: users can stomp all over each others' namespaces, and wreak havoc with each others' scripts. Yes, there are solutions for this, but none is as easy to implement and maintain as not using mod_perl in the first place.

Alan

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)];

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.

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();

I'd say it's definately worth playing around with FastCGI. Apart from the fine tuning aspects the fact the the code becomes more portable (i.e. the code could run with Apache, as in your case) is a big plus point. After all what's the point in writing some nice generic modules if suddenly you have to change servers (for whatever reason) and it stops working?

Thats my 2 cents anyway.

You're bang on with that.

I've used FastCGI for a long time now. I spent half an hour with Apache::Perl and didn't find is as instantly accessable so I still use FastCGI.

I believe this is down to my laziness rather than anything else.

Performance increase is extremely impressive. As a testy-fudgy-see-how-I-can-thrash-Apache test, I wrote a quick CGI routine which was basically an XML server which listened for requests and could also call itself to recurse informtation.

Utterly brutal way of doing things, but heck - it was a laugh.

Running as a simple CGI, a request which called itself around 14 times (all in all, about 15 executions of the same CGI) came back with result in 10 seconds.

By simply changing it to run as a fast-cgi script, the results arrived after 0.3 seconds.

I am sure, if I were to investigate using Apache::Perl, that I could have the same results.

I think it's all down to whatever floats your boat really. Interesting to see how passionate some monks are about this subject though.

--
Gregor Anderson, Edinburgh. http://www.deletia.org/