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

Michael Shadle mike503 at
Wed Dec 9 04:13:24 MSK 2009

On Tue, Dec 8, 2009 at 4:46 PM, nerdgrind <nginx-forum at> wrote:

> Apache is rock solid. That's a fact. Keep reading to see how many web sites support this fact.

It is stable, yes. Does it scale as well? No.

> php-fcgi is unstable, and unreliable. That's a fact. It's no joke when a web site goes down on a production server. Down time is lost money.

PLEASE give me these thousands of complaints against php-fcgi. The PHP
team should probably hear about them since it is such an epidemic.

> The forums are saturated with complaints about the instability and unreliability of php-fcgi, etc., serving PHP for Nginx and other servers that don't serve PHP themselves.

Perhaps using newer versions of PHP-FPM or something.

> When Apache, or Litespeed, are used on the backend to serve PHP for Nginx, and those other static file servers like Zeus and lighttpd, there are zero complaints, because Apache is reliable and stable when serving PHP.

Zeus doesn't use Apache for PHP. It uses FastCGI. Why? Because it is
decoupled from the webserver and offers better scaling methods.

FastCGI has been around since what, 1994 or something? It might have a
couple flaws according to some folks, but it has proven to be solid,
otherwise commercial vendors such as Zeus would not be using it. Zeus
would not be able to sell their product if PHP support was broken.

> ... you must have never used Apache to serve millions of request, because I have, and I know you have no idea what you're talking about, and the system administrators handling some of the biggest web sites on the Internet also know you don't have a clue about Apache's abilities.

No, I used Apache, until it took my server load to 40+ and became
unresponsive. Then I switched to Zeus + PHP over FastCGI. Amazingly,
my server load dropped to 2.00 and it was not lagged at all, I had to
load the site to verify it was actually running. It seemed virtually

> Post the URL to your web site that handles millions of requests a day, because I believe you're claim is a lie. The only site I can find for you is, and that doesn't get much traffic at all.

I have a variety of client sites that I host and I don't need to
justify them to you. I have a 3 node web cluster that hosts multiple
PHP-FPM fastcgi pools with -no- downtime or issues. Total amount of
PHP-based requests is in the millions/day. It would be a breach of my
clients' privacy to be posting their websites. Call it a lie all you
like, I would not be selling something I didn't believe in, and you
can take that to the bank.

Apache's only solution for uid/gid-based execution for PHP would be
suexec. Forget using anything else, it scales even worse. Unless
you're going to use suexec or multiple Apache instances, you cannot
emulate the pool concept.

> uses Apache, uses Litespeed, uses Nginx on the frontend with Litespeed on the backend. uses Apache. uses Apache, they must have switched from lighttpd because of the memory leak, or maybe because of problems with php-fcgi.

Maybe you should research first. YouTube has no claims to be using PHP:

Also, WordPress was so impressed by nginx, they were thinking of using
it for their web nodes to simplify their software stack. That would be
a major change though, so who knows if they still are thinking about
it or are happy where they are at.

Livejournal also does not use PHP. It uses Perl, like everything at
Danga seems to.


Do you notice nginx's growing trend? Not to mention 4th on the list?
That is like saying "Porsche sucks, it only has 3% of the car market.
It's obvious Toyota is better because it has 40%" or something. Apache
is king because it's been around for a long time, it's more accessable
and is the default in half the Linux-based server installations out

I've yet to have anyone try nginx who didn't want to go back.

I've yet to see anyone complain FastCGI+PHP was too unstable for their needs.

> I guess some of the highest trafficked web sites on the Internet are using a web server that doesn't use php-fcgi to handle PHP.

Possibly because they aren't using PHP? Not like you for a "high
traffic blog" site.

> What's more important is that there is no way to know how many web sites are using Apache or lighttpd as a backend server to handle PHP, since those people never complain about problems, and the small number of web sites that do try to use php-fcgi complain on forums all over the Internet about problems with reliability and stability.

Then those people are -idiots- - I said it. I see nginx mailing list
issues daily. Are any of them due to a PHP+FastCGI issue? No. Has that
ever been the breaking point? No. In fact, for most people moving AWAY
from a mod_php model has proven more scalable.

(Hey folks now is time to show those impressive benchmarks you paste
all around IRC and such :p)

> Those are the facts Mike. Your support for php-fcgi sounds more like an opinion than a statement based on fact.

You got me there! You've got the facts obviously. Even though multiple
ones are wrong. They are 'facts' nonetheless.

> I've seen your comments here about how much you love php-fpm. Giving people the impression that php-fcgi is the only option they have to handle PHP on the backend, can mislead someone into many hours or days of frustration that can lead them into dumping Nginx, because they blame Nginx for the problems caused by php-fcgi. I suggest balancing your advice with other options like Apache.

Or I will give advice as I see fit, as it is advice. If they come to
the list saying their PHP is not scaling properly, then we'll address
that issue. I mentioned using PHP-FPM but I was willing to try to help
you with spawn-fcgi.

It sounds like you've got a crappy platform or crappy code to be
crashing PHP processes. Perhaps the only reason you think Apache is
stable is because it's acting as a process monitor itself and is
either restarting children and you're unaware, or is a bit more
resilient to whatever code is crashing your children under FastCGI.

More information about the nginx mailing list