Fast CGI (spawn-fcgi / php-cgi) crashes/dies/hangs

[Michael Shadle]

On Wed, Dec 9, 2009 at 1:01 AM, Igor Sysoev <igor at sysoev.ru> wrote:

> I believe FastCGI has appeared in circa 1999, when Apache's mod_php/mod_perl
> were well known solutions, therefore, FastCGI was not widespread at those
> times. FastCGI has got the second breath with lighttpd, then nginx.
> BTW, initially I did not plan to support FastCGI: the first nginx's
> FastCGI support has appeared in 0.1.14. At work we use mainly mod_perl
> as a backend.

I had looked it up on Wikipedia and it said "mid 90's" and I swore I
had read 1994 somewhere. But it's been around long enough to be
proven, albeit with some limitations (which is why people want things
like SCGI)

You think Lighty brought new light to it? I was using Zeus for years
before using Lighty and it required FastCGI too for PHP support. It's
always been around, but maybe Lighty broke out so popular so quickly
for a while there it really brought attention to it I guess.

Anyone who doubts if FastCGI is useless only has to look to see that
Apache has at least 2 FastCGI modules. People still suggest it for
better separation of PHP and other FastCGI application tiers than
glued in the webserver. In fact I remember saying "hey there should be
a mod_php in Lighty!" along with other people and it was always turned
down - "why bloat the webserver up with a PHP engine, pass the request
off instead"

FastCGI allows for transparent scaling out too, all of a sudden your
machine is no longer a bottleneck because you can push the FCGI
processing out to -other- nodes. It just increases the options
available for scaling and is not any more crash-prone than Apache (as
Grzegorz greatly improved upon my original text)

Either way, it's been great in nginx, I have no complaints. Was pretty
easy to move too since I was already using FastCGI with Zeus for years
and Lighttpd for over a year or so. Didn't have to alter my PHP
configuration for it or worry about changing from .htaccess to server
level settings.