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

Apologies if this is too off topic. My problem is not directly related 
to nginx.

We've been running nginx + spawn-fcgi for 6 months without any issues. 
Until one morning I come in and all our sites are down because there 
were no php-cgi processes running. Obviously I'm keen to not have this 
happen again. I could make use of something like monit to monitor the 
php-cgi processes, but even a few minutes down time (waiting for a monit 
cycle) is not good.

The only article on this I've been able to find so far is this one: 
http://blog.taragana.com/index.php/archive/how-to-stop-crashing-hanging-of-php-cgi-spawn-fcgi-with-nginx-lighttpd/

As this is a popular combo with nginx, I was wondering if anyone here 
had any advice, or even just some more articles for me to RTFM?

Thanks.

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,28783#msg-28783

Use php-fpm instead :)

mike Wrote:
-------------------------------------------------------
> Use php-fpm instead :)

This would require re-compiling PHP, which I am not prepared to do 
unless critical. Too many other potential head-aches from this.

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,28818#msg-28818

well spawn-fcgi not working properly could be considered critical.

have you tried the latest stable spawn-fcgi, and then the latest beta?

On Tue, Dec 08, 2009 at 03:33:05AM -0800, Michael Shadle wrote:
> well spawn-fcgi not working properly could be considered critical.
> 
> have you tried the latest stable spawn-fcgi, and then the latest beta?

It won't work anyway.

Repeat after me.

spawn-fcgi is not a process manager. spawn-fcgi is not a process 
manager.
spawn-fcgi is not a process manager. spawn-fcgi is not a process 
manager.
spawn-fcgi is not a process manager. spawn-fcgi is not a process 
manager.
spawn-fcgi is not a process manager. spawn-fcgi is not a process 
manager.
spawn-fcgi is not a process manager. spawn-fcgi is not a process 
manager.

No version of spawn-fcgi will help you (or the OP) with crashing PHP
processes. Use a process manager, like supervisord, god, runit, upstart,
sysvinit, daemontools or whatever suits you, that can actually restart a
crashed PHP.

(shameless plug: consider supervisord with ngx_supervisord, announced
here recently)

Best regards,
 Grzegorz Nosek

roger that. just wondering why they're crashing under spawn-fcgi to 
begin with.

and also ... we all know php-fpm is a process manager too. two birds
with the same stone! ;)

On Tue, Dec 08, 2009 at 03:52:24AM -0800, Michael Shadle wrote:
> roger that. just wondering why they're crashing under spawn-fcgi to begin with.

Running php-fcgi with -b option is AFAIK completely equivalent to
running it via spawn-fcgi. spawn-fcgi really has nothing to do with PHP
crashes.

> and also ... we all know php-fpm is a process manager too. two birds
> with the same stone! ;)

Yup, but the OP doesn't want to recompile PHP, so sue him ;)

Best regards,
 Grzegorz Nosek

> On Tue, Dec 8, 2009 at 3:55 AM, Grzegorz Nosek <grzegorz.nosek@gmail.com> wrote:

Once again, you've enhanced my statement. You're right. I've been
discussing random php-fpm stuff on IRC and such and was thinking
spawn-fcgi actually -did- something additional that php-cgi -b didn't
do and had some php guts in it or something.

Time to go to bed :)

On Tue, Dec 08, 2009 at 03:59:20AM -0800, Michael Shadle wrote:
                        ^^^^^^^^^^
> Time to go to bed :)

Indeed :)

Best regards,
 Grzegorz Nosek

You could use Apache to serve PHP scripts rather than 
spawn-fcgi/php-cgi. Apache's handling of PHP has been time tested, and 
performs as well or better than fcgi in my experience on a high traffic 
Wordpress blog.

We use:


proxy_pass         http://127.0.0.1:8008;


Apache can listen on several ports.

I had a lot of headaches with fcgi, which made me question why I even 
needed it when I had Apache. On a single server Apache handled PHP and 
static files for 35 million visitors in a month before we started using 
Nginx, so using Apache only for PHP on the backend made sense.

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,29032#msg-29032

This boggles my mind. Apache just for php...

Sent from my iPhone

Mike,

I know you're a superfan of php-fpm, and fcgi in particular, but some of 
us have very high traffic blogs that require 100% uptime if possible, 
which Apache can provide. php-fpm, spawn-fcgi, and php-fcgi are for 
small blogs that can afford to experiment, and aren't going to lose 
money when fcgi crashes or hangs.

Apache is rock solid when handling PHP, and this is a fact. fcgi has 
stability issues even when the php-fpm patch is installed.

I understand your enthusiasm, but until you're blog is getting millions 
of visitors each month you cannot really test the stability of php-fpm 
on your production server.

What's boggles my mind is hearing so many people recommend any flavor 
fcgi for PHP despite all the instability, crashing, and hanging issues 
that continue to be unresolved, when nearly every server comes with 
Apache which handles PHP in a stable and reliable manner right out of 
the box.

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,29041#msg-29041

php-fpm handles millions of requests a day for me without an issue.
Apache cannot handle the load on the same hardware.

Go figure.

FCGI for PHP is not only stable but time tested as well. You'll note
that Zeus, lighttpd, nginx, almost every webserver with a user base
sans litespeed and Apache can *only* use PHP over fastcgi.

PHP-FPM isn't for everyone but soon can be. I gave my (as Norsek
pointed out useless) help w/ spawn-fcgi questions. I  understand it's
not an option for some but calling PHP over FCGI unstable is a joke :)

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

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.

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.

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.

When you say:

Apache cannot handle the load on the same hardware.


... 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.

You said:

php-fpm handles millions of requests a day for me without an issue.


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 http://michaelshadle.com/, and that doesn't get much traffic at 
all.

http://community.livejournal.com uses Apache, http://wordpress.org/ uses 
Litespeed, http://wordpress.com/ uses Nginx on the frontend with 
Litespeed on the backend. http://www.techcrunch.com uses Apache. 
http://youtube.com/ uses Apache, they must have switched from lighttpd 
because of the memory leak, or maybe because of problems with php-fcgi.

http://wikipedia.org/ uses Apache, and Xcache.

http://news.netcraft.com/archives/web_server_survey.html


Developer  October 2009  Percent  November 2009  Percent  Change
Apache          108,078,535  46.90%  110,201,883  47.17%  0.27
Microsoft  49,723,999  21.58%  49,691,412  21.27%  -0.31
qq.com          30,069,136  13.05%  30,069,189  12.87%  -0.18
nginx          13,813,997  5.99%  14,988,610  6.42%  0.42
Google          13,819,947  6.00%  13,771,004  5.89%  -0.10
lighttpd  1,020,227  0.44%  1,113,605  0.48%  0.03


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.

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.

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

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.

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,29065#msg-29065

I managed a forum with a million visitors/DAY. I used nginx with php-fpm 
without any problems.

Love nginx + php-fpm :)



Best Regards,

Glen Lumanau

On Tue, Dec 8, 2009 at 4:46 PM, nerdgrind <nginx-forum@nginx.us> 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.
Sorry.

> ... 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
unaffected.

> 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 http://michaelshadle.com/, 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.

> http://community.livejournal.com uses Apache, http://wordpress.org/ uses Litespeed, http://wordpress.com/ uses Nginx on the frontend with Litespeed on the backend. http://www.techcrunch.com uses Apache. http://youtube.com/ 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:
http://highscalability.com/youtube-architecture

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.
http://highscalability.com/blog/2007/7/9/livejournal-architecture.html

> http://news.netcraft.com/archives/web_server_survey.html

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
there.

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.

nerdgrind wrote:
> Apache is rock solid. That's a fact. Keep reading to see how many web sites support this fact.
> 
> 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.
> 
> 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.

As they are with Apache dying. Google it.

> 
> 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.

Zero complaints? You know this for a fact? Zero? You must be kidding.
Making statements like this does little for your credibility.

> php-fpm handles millions of requests a day for me without an issue.
> 
> 
> 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 http://michaelshadle.com/, and that doesn't get much traffic at all.

That's out of line. Just because YOU cannot find it does not mean it is
not there. It is, but you don't know where to look and Mike is not going
to share it to satisfy your need to know. You're wrong on this one.

> Microsoft  49,723,999  21.58%  49,691,412  21.27%  -0.31
> qq.com          30,069,136  13.05%  30,069,189  12.87%  -0.18
> nginx          13,813,997  5.99%  14,988,610  6.42%  0.42
> Google          13,819,947  6.00%  13,771,004  5.89%  -0.10
> lighttpd  1,020,227  0.44%  1,113,605  0.48%  0.03
> 
> 
> 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.

And some use nginx. As for how they handle PHP, that is speculation.

> 
> 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.

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

This may be but your claim that there are zero complaints with Apache
and that Apache is "rock solid" and never goes down is also an opinion
that happens to be wrong. I have myself seen it go down. Of course we
were only handling 4 million requests/day at the time and we were using
Apache with mod_perl to serve a Perl script, so it wasn't PHP. That's
why I had supervisord installed. It can restart php-cgi just as easily
(and probably php-fpm but I haven't tried it) as it can Apache and even
nginx. The fact that I never posted my experience on a forum doesn't
mean it never happened.

> 
> 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.

This is a fair comment. Mike loves php-fpm and is perhaps biased. So sue
him.

This "discussion" probably does not belong on the nginx list and should
perhaps be taken private between you two if it needs to continue.

> 
> Posted at Nginx Forum: http://forum.nginx.org/read.php?2,28783,29065#msg-29065
> 
> 
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx


--
Jim Ohlstein

Jim Ohlstein Wrote:
-------------------------------------------------------
> down is also an opinion 
> nginx. The fact that I never posted my experience
> on a forum doesn't 
> mean it never happened.

Correction: I used monit to restart Apache at that time. Previously I 
had used my own shell script.

>

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,29076#msg-29076

Gentlemen,

I respect your'e opinions, but for all you're heated desperation to 
defend php-fcgi you may have forgotten this thread was started by 
someone who found php-fcgi to be unstable, and he hasn't been able to 
find a solution. I found one that worked for me when php-fcgi failed. 
Offering a solution to someone that results in the same failure doesn't 
seem to be a solution to me.

Perhaps someone here could give a detailed solution as to how miradev 
might solve his problem. Kind of like a how-to explanation. We're all 
here to help each other.

I don't want to anyone coming here for help only offered one 
possibility, when something else might be better suited to their 
situation and needs, which is why I posted an alternative.

Apache may not be on the most loved list here, but it can work where 
php-fcgi fails. Let's not ignore this alternative when someone is ready 
to switch from Nginx back to Apache, as even the author of WP Super 
Cache did just last week. Insisting that php-fcgi is the only way to 
serve PHP will slow the adoption of Nginx, because it doesn't offer 
support for PHP itself.

In fact, Wordpress itself has a problem when php-fcgi is used rather 
than Apache as the backend to serve PHP

http://wordpress.org/extend/plugins/nginx-compatibility/


When WordPress detects that FastCGI PHP SAPI is in use, it disregards 
the redirect status code passed to wp_redirect. Thus, all 301 redrects 
become 302 redirects which may not be good for SEO. The plugin overrides 
wp_redirect when it detects that nginx is used.

When WordPress detects that mod_rewrite is not loaded (which is the case 
for nginx as it does not load any Apache modules) it falls back to 
PATHINFO permalinks in Permalink Settings page. nginx itself has 
built-in support for URL rewriting and does not need PATHINFO 
permalinks. Thus, when the plugin detects that nginx is used, it makes 
WordPress think that mod_rewrite is loaded and it is OK to use pretty 
permalinks.


There is also an extensive additional configuration that needs to be 
done to avoid problems.

http://wordpress.org/extend/plugins/nginx-compatibility/other_notes/

I've never heard anyone hear discuss these issues, which means a lot of 
people might be losing out on a lot of traffic that could be coming from 
search engines because of an SEO problem caused by an incompatibility 
between php-fcgi and Wordpress.

Using Apache as a backend eliminates this problem.

Like many of you, I have had my own experiences, and I now have a 
multitude of solutions to fit different situations. Although I don't 
know what platform miradev uses to serve his web sites, if it is 
Wordpress then using Apache on the backend could save him some headaches 
he didn't even know existed.

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,29087#msg-29087

On Tue, Dec 8, 2009 at 6:21 PM, nerdgrind <nginx-forum@nginx.us> wrote:

> I respect your'e opinions, but for all you're heated desperation to defend php-fcgi you may have forgotten this thread was started by someone who found php-fcgi to be unstable, and he hasn't been able to find a solution. I found one that worked for me when php-fcgi failed. Offering a solution to someone that results in the same failure doesn't seem to be a solution to me.

Not desperation. I think it's more "responding to outlandish claims"

Perhaps you need someone else to help you set it up as you seem to be
having some issues getting a reliable solution going using FCGI. None
of us seem to have issues.

> I've never heard anyone hear discuss these issues, which means a lot of people might be losing out on a lot of traffic that could be coming from search engines because of an SEO problem caused by an incompatibility between php-fcgi and Wordpress.

Or, WordPress just needs a patch to change the behavior, if that is
truly the case. WP should not be sniffing the SAPI to determine
behavior, that's weird, but WP already does a bunch of weird things.

People use WP Supercache with nginx all the time. Perhaps it's issuing
the wrong redirect header, but it at least works. I don't remember
what the OP was asking in the beginning but if it doesn't work then
there is something else going on. If the issue was the wrong type of
redirect being issued, that's not something that can be fixed by nginx
- that's a WP issue. Switching webservers because of that seems a bit
overkill; I would submit a bug with WP for it, it is small and I would
think it should be able to get in the next release.

Mike,

On your website perhaps you could post all the configurations you use to 
run php-fpm, including the events file from Ubuntu you use to respawn 
php-fpm.

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,29118#msg-29118

Perhaps in a little bit - however, I don't supervise php-fpm with 
anything.

If you're referencing something I said in the past about using
upstart, that was in combination directly with php -b $port

I had one file per pool

I think I've posted that somewhere on the net, I can't find it right
now. But I'm all about transparency (as long as it still retains
privacy)

Note I am using php 5.2.11 w/ the patch from php-fpm.org, my build
script for PHP is this, it works like a charm on CentOS 5.x x86_64,
Ubuntu various versions in 64-bit, and I think I even had it running
under 32-bit just had to remove a couple compile options.

This same pattern of compiling has been in place for many versions of
php 5.2.x, it also seems to work for 5.3.x but I have not tested that
in production yet because I don't think a lot of my clients' code will
work with 5.3.x - yes, I have to support a LOT of crappy code, and
millions of requests a day on it :)

I do want to share this in some sort of wiki-ish fashion. All my
little snippets of code and any changes I make to them and why. People
over-complicate nginx configurations for things all the time for
example.

Note: using this on a modern CentOS/RHEL/Fedora or Ubuntu system
should be stable.

#!/bin/bash
VER=5.2.11
BD=`pwd`

rm -rf php-${VER}
wget -c http://us3.php.net/get/php-${VER}.tar.gz/from/this/mirror
tar xvfz php-${VER}.tar.gz
cd php-${VER}

wget -c http://php-fpm.org/downloads/php-${VER}-fpm-0.5.13.diff.gz
gunzip php-${VER}-fpm-0.5.13.diff.gz
patch -p1 < php-${VER}-fpm-0.5.13.diff

wget -c http://download.suhosin.org/suhosin-patch-${VER}-0.9.7.patch.gz
gunzip suhosin-patch-${VER}-0.9.7.patch.gz
patch -p1 < suhosin-patch-${VER}-0.9.7.patch

./configure \
--enable-fastcgi \
--enable-discard-path \
--enable-force-cgi-redirect \
--enable-fpm \
--with-fpm-pid=/var/run/php-fpm.pid \
--with-fpm-log=/var/log/php-fpm.log \
--with-fpm-conf=/etc/php-fpm.conf \
--enable-cli \
--enable-inline-optimization \
--disable-rpath \
--disable-ipv6 \
--enable-mbstring \
--enable-mbregex \
--enable-sqlite-utf8 \
--with-gettext \
--with-mysql \
--with-mysqli=/usr/bin/mysql_config \
--with-curl \
--with-zlib \
--with-gd \
--with-jpeg-dir=/usr \
--with-png-dir=/usr \
--with-freetype-dir \
--enable-gd-native-ttf \
--enable-exif \
--enable-shmop \
--with-xsl=shared \
--with-mssql=shared \
--enable-soap=shared \
--enable-sockets \
--enable-pcntl=shared \
--with-mcrypt \
--with-bz2 \
--with-tidy \
--with-pcre-dir \
--with-openssl \
--with-imap=shared \
--with-imap-ssl \
--with-kerberos \
--with-pear \
--with-gmp
make -j4
make install
cd $BD
rm -rf php-${VER} php-${VER}.tar.gz

You make it sound like it a problem of nginx or php-fcgi while, in fact, 
it's
a bug (yes, a bug, not a "compatibility issue") of Wordpress.
Enough trolling, go fix it and move on already!

On Tue, Dec 08, 2009 at 09:21:18PM -0500, nerdgrind wrote:
> Gentlemen,
> 
> I respect your'e opinions, but for all you're heated desperation to defend php-fcgi you may have forgotten this thread was started by someone who found php-fcgi to be unstable, and he hasn't been able to find a solution. I found one that worked for me when php-fcgi failed. Offering a solution to someone that results in the same failure doesn't seem to be a solution to me.

Hi,

PHP is utter crap. It *does* crash regularly, deep inside its bowels,
regardless of whatever thin interface to the outside world (SAPI) you
use. You simply have to plan for it and expect SEGVs flying back and
forth.

Using mod_php simply hides the crashes from you and you might have been
blissfully unaware of the problem (how are you going to log it if your
web server went down together with PHP? Also, many PHP bugs come up when
cleaning up after a request, so you wouldn't ever notice it apart from a
"child terminated with sig11" in error.log).

So now you blame the FastCGI SAPI, which also needs external help to
keep running.

I've been using Apache+php-fcgi for years now without major issues
related to FastCGI. Under this scheme Apache is a poor process manager
and a heavyweight .htaccess interpreter/static file server.

BTW, I don't think I could care less about your method of running PHP, I
just want to keep the facts straight. http://xkcd.com/386/ I guess.

Best regards,
 Grzegorz Nosek

Nosek,

That cartoon was great! Thanks for injecting some realistic humor into 
the mix.

All the best,

Todd

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,29144#msg-29144

On Tue, Dec 08, 2009 at 05:13:24PM -0800, Michael Shadle wrote:

> > 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.
> Sorry.

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.


--
Igor Sysoev
http://sysoev.ru/en/

miradev wrote:
> We've been running nginx + spawn-fcgi for 6 months without any issues. Until one morning I come in and all our sites are down because there were no php-cgi processes running. Obviously I'm keen to not have this happen again. I could make use of something like monit to monitor the php-cgi processes, but even a few minutes down time (waiting for a monit cycle) is not good. 
>
> The only article on this I've been able to find so far is this one: http://blog.taragana.com/index.php/archive/how-to-stop-crashing-hanging-of-php-cgi-spawn-fcgi-with-nginx-lighttpd/
>   
I had a very similar problem when using lighttpd+spawn-fcgi. We had
moved from Apache about 3 years ago because of load issues with mod_php
to lighttpd+spawnfcgi+php. This worked fine for a while, but as our load
increased we started to see PHP being unresponsive, and lighty returning
503s.

After some digging I found the cause was the way spawnfcgi handled
incomming requests in conjunction with PHP's internal
PHP_FCGI_MAX_REQUESTS setting. This setting is set to 250 by default in
PHP, and when this limit is hit PHP recycles the child thread. During
this recycle spawnfcgi would continue to handle requests, pass them to
the recycling thread, get no response, and in turn lighty would return a
503. IIRC this would also cause the recycling thread to die, slowly
killing off all the threads and PHP completely.

Playing with PHP_FCGI_MAX_REQUESTS helped in the short-term but we
continued to experience the problem, so when I heard of nginx I quickly
switched to nginx+php-fcgi (using the -b switch). Since then I've yet to
see an issue, and we've had ~100 production sites running on that stack
for over 2 years. Since starting to use supervisord we've begun the
process of moving the rest of our ~500 domains/sites over to to that 
stack.

Using PHP `-b` in my experience is rock-solid. Running it under
supervisord means that if it dies it is brought back up straight away.
This does not affect nginx, and you can always show a nice error page
should this case happen - I remember that if php went down hard under
mod_php it would cause apache to fail also. Bad times.

My suggestion is to get rid of spawnfcgi and install supervisord. Here's
the supervisord config I use on my dev machine:

[fcgi-program:php]
user=nginx
command=/usr/bin/php-cgi -c /etc/php5/php.ini -b /tmp/php.socket
socket=unix:///tmp/php.socket
autostart=true
startsecs=5
startretries=3
stopwaitsecs=10
environment=PHP_FCGI_MAX_REQUESTS=50,PHP_FCGI_CHILDREN=4

Some on the board suggest having nginx running under supervisord also,
but I'm a little worried about that approach; if supervisord goes down
for any reason on a live server everything goes down, whereas if nginx
is kept separate and supervisord goes down nginx can continue to serve
requests (albeit error pages) while supervisord comes back up and brings
your app back online (php, database, memcached, etc).

Our production runs:
  supervisord > php-fcgi, mysqld, memcached, and a number of python
"services" (our webapp layer)
  monit > nginx, supervisord, sshd, other "system" level important 
daemons
which means if supervisord goes down for any reason, it'll only be down
for 1min until monit can bring it back up. Since memcached is killed our
webapp is brought back up in a "clean" state. Users are asked to log in
again, but this rarely (or, rather, is yet to) happens and is a mild
inconvenience for them.

Give it a try. All these technologies are highly configurable and there
are many permutations. To find your optimal configuration is going to
take experimentation. It's not like Apache where there's only one
"right" way to do things; you've got more control - make use of it!

--

*Phillip B Oldham*
ActivityHQ
phill@activityhq.com <mailto:phill@theactivitypeople.co.uk>

------------------------------------------------------------------------

*Policies*

This e-mail and its attachments are intended for the above named
recipient(s) only and may be confidential. If they have come to you in
error, please reply to this e-mail and highlight the error. No action
should be taken regarding content, nor must you copy or show them to 
anyone.

This e-mail has been created in the knowledge that Internet e-mail is
not a 100% secure communications medium, and we have taken steps to
ensure that this e-mail and attachments are free from any virus. We must
advise that in keeping with good computing practice the recipient should
ensure they are completely virus free, and that you understand and
observe the lack of security when e-mailing us.

Igor Sysoev 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'm still hoping to see SCGI in a future release. It would greatly
simplify my nginx + wsgi set-up!

--

*Phillip B Oldham*
ActivityHQ
phill@activityhq.com <mailto:phill@theactivitypeople.co.uk>

------------------------------------------------------------------------

*Policies*

This e-mail and its attachments are intended for the above named
recipient(s) only and may be confidential. If they have come to you in
error, please reply to this e-mail and highlight the error. No action
should be taken regarding content, nor must you copy or show them to 
anyone.

This e-mail has been created in the knowledge that Internet e-mail is
not a 100% secure communications medium, and we have taken steps to
ensure that this e-mail and attachments are free from any virus. We must
advise that in keeping with good computing practice the recipient should
ensure they are completely virus free, and that you understand and
observe the lack of security when e-mailing us.

On śro, gru 09, 2009 at 09:08:29 +0000, Phillip Oldham wrote:
> Some on the board suggest having nginx running under supervisord also, 
> but I'm a little worried about that approach; if supervisord goes down 
> for any reason on a live server everything goes down, whereas if nginx 
> is kept separate and supervisord goes down nginx can continue to serve 
> requests (albeit error pages) while supervisord comes back up and brings 
> your app back online (php, database, memcached, etc).

If you mean ngx_supervisord we have announced recently here, you might
have misunderstood. We don't advocate running nginx under supervisord,
we enable nginx to communicate with supervisord to start/stop backends
according to load.

If you meant something else, I must have missed it, because I don't
recall any other mentions of supervisord on this list.

Best regards,
 Grzegorz Nosek

Oldham,

Would you be kind enough to share your supervisord configs for mysqld 
and memcached as well?

All the best,

Todd

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,29162#msg-29162

Grzegorz Nosek wrote:
> If you mean ngx_supervisord we have announced recently here, you might
> have misunderstood.
>   
No, sorry - running nginx "under" supervisord, and therefore having
supervisord manage nginx should it die unexpectedly.
> If you meant something else, I must have missed it, because I don't
> recall any other mentions of supervisord on this list.
I may have gotten confused with the supervisord list; I'm a member of
both, as I know some other members of the nginx community are. :)

On Wed, Dec 9, 2009 at 1:09 AM, Phillip Oldham <phill@activityhq.com> 
wrote:

> I'm still hoping to see SCGI in a future release. It would greatly simplify
> my nginx + wsgi set-up!

Yeah that seems to be people's "this is better than FCGI" but can't
seem to get a lot of traction.

On Wed, Dec 9, 2009 at 1:08 AM, Phillip Oldham <phill@activityhq.com> 
wrote:

> Our production runs:
>   supervisord > php-fcgi, mysqld, memcached, and a number of python
> "services" (our webapp layer)
>   monit > nginx, supervisord, sshd, other "system" level important daemons
> which means if supervisord goes down for any reason, it'll only be down for
> 1min until monit can bring it back up. Since memcached is killed our webapp
> is brought back up in a "clean" state. Users are asked to log in again, but
> this rarely (or, rather, is yet to) happens and is a mild inconvenience for
> them.

Wow - I don't use any supervisor daemons for anything and I never seem
to have any issues. Overall I suppose it's a lot nicer having
technology monitor itself though. It would be totally cool if you
posted the configs for all of those!

Let me just start with a 'thank you' to you all for your spirited 
replies. Seriously. I would dearly like to answer you all individually, 
but I'm not sure that'd be sensible :)

We're a small outfit, with me as the only permanent IT person 
(development, admin, support e.t.c).

The relevant production setup is Rackspace managed Redhat. The 
requirement I am looking for is a small footprint solution that can 
ultimately be ported elsewhere (e.g. slicehost). I want to keep things 
as much 'out of the box' as possible, as Rackspace then take away a lot 
of my headaches. Anything I play with does not fall under their 
contractual obligations (this is my main reason for not recompiling 
PHP).

This particular server setup is: nginx at the front, from which things 
split two ways. One way is to Apache+mod_perl which (unavoidably) 
creates *large* threads (serving some heavy data-munging). The second is 
fcgi+php mainly serving Wordpress. Currently the two 'services' must 
live side-by-side on one server (love the legacy).

The reason for not using Apache for WP is twofold. Firstly, apache has a 
higher memory footprint making it unsuitable for us to scaling down to, 
for example, a 256MB slice. Secondly, I don't want it sharing the large 
apache threads and I haven't found a way of reliably running a second 
apache configuration alongside.

I'm convinced that my initial premise (this is not an nginx issue) is 
correct, so if this is too offtopic I am happy to continue this 
elsewhere.

What I have learnt, from reading this thread, and some more web content, 
is that there is nothing wrong with my setup. I'm pretty happy with 
apache and fcgi in a stand-alone situation. So I am going to stick with 
ngnix+php-cgi. Which means I need to manage/admin things better.

The advice I will take is to install supervisord on my dev box and learn 
how to manage my php-cgi processes properly. One crash in 6 months is 
not indicative of a systemic problem.

Thanks.

PS:

I know spawn-fcgi is not a process manager. I know spawn-fcgi is not a 
process manager.
I know spawn-fcgi is not a process manager. I know spawn-fcgi is not a 
process manager.
:)

PPS: nginx rules ko!

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,29193#msg-29193

On Wed, Dec 9, 2009 at 1:01 AM, Igor Sysoev <igor@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.

On Wed, Dec 9, 2009 at 4:24 AM, miradev <nginx-forum@nginx.us> wrote:

> The reason for not using Apache for WP is twofold. Firstly, apache has a higher memory footprint making it unsuitable for us to scaling down to, for example, a 256MB slice. Secondly, I don't want it sharing the large apache threads and I haven't found a way of reliably running a second apache configuration alongside.

Exactly. mod_php will make each Apache thread or process larger, even
if it's just serving up static files in that thread for a while.

> What I have learnt, from reading this thread, and some more web content, is that there is nothing wrong with my setup. I'm pretty happy with apache and fcgi in a stand-alone situation. So I am going to stick with ngnix+php-cgi. Which means I need to manage/admin things better.

You shouldn't need two webservers or even worry about it. nginx is
super fast and lean for static files and also probably the leanest
when it comes to processing PHP [passing the request off], assuming
your backend FastCGI process manager is not wasting resources and you
compile or use as little PHP built-in modules as you need. (My install
has a handful of built-ins, I tried to split off some into shared
modules though, but I also don't run things inside of a small VPS :))

It would be interesting to take a benchmark of memory used for
something like Apache+mod_php vs. nginx+PHP-FPM or nginx+spawn-fcgi
and set the number of processes for PHP the same in both and see
memory usage after hitting it with some load for a few minutes. As
close to an apples and apples comparison. Of course, Apache will
always be spawning more full threads/processes for additional load
whereas a standalone FCGI process in PHP will only be loading a PHP
process to service more load. So in theory, it should be more
lightweight off the bat, at least when it comes time to increase the #
of concurrent requests you can process.

> The advice I will take is to install supervisord on my dev box and learn how to manage my php-cgi processes properly. One crash in 6 months is not indicative of a systemic problem.

Everything breaks. Especially technology related. Once in 6 months
isn't bad at all IMHO :)

On Wed, Dec 09, 2009 at 04:31:37AM -0800, Michael Shadle wrote:

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

Sorry, I missed, it's dated back 1996:
http://www.fastcgi.com/drupal/node/6?q=node/15
http://www.fastcgi.com/devkit/doc/fastcgi-prog-guide/cover.htm

> 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.

I meant popularity.


--
Igor Sysoev
http://sysoev.ru/en/

On 12/9/09 7:39 AM, "Michael Shadle" <mike503@gmail.com> wrote:
> something like Apache+mod_php vs. nginx+PHP-FPM

To be fair, you should test Apache+fastcgi.  It's the "official" way to 
run
it, although everyone stills seems to use mod_php.

I have no doubt that nginx still wins, but the Apache folks have been
pushing fastcgi for several years, it just hasn't got traction for some
reason.



--
Brian Akins

On Wed, Dec 9, 2009 at 7:51 AM, Akins, Brian <Brian.Akins@turner.com> 
wrote:
> On 12/9/09 7:39 AM, "Michael Shadle" <mike503@gmail.com> wrote:
>> something like Apache+mod_php vs. nginx+PHP-FPM
>
> To be fair, you should test Apache+fastcgi.  It's the "official" way to run
> it, although everyone stills seems to use mod_php.
>
> I have no doubt that nginx still wins, but the Apache folks have been
> pushing fastcgi for several years, it just hasn't got traction for some
> reason.

That's funny, considering we were just told that PHP+FCGI was the most
unreliable setup, to have someone saying Apache was pushing it as
well. :)

I'm not interested in this benchmark (nginx and PHP-FPM are stable and
run as slim as I think they can for me) but it would be some good
tangible information to be able to reference.

It probably has no traction because of legacy habits. Also, I think I
tried FastCGI w/ Apache once and it was a little bit odd, might have
been trying to do suexec+FastCGI for PHP though and that complicates
things a bit. Tried mod_fastcgi and mod_fcgid...

miradev,

Can you post your fcgi init script? I am also using a RHEL5 OS, and 
would like to see how yours compares with my own.

All the best,

Todd

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,29349#msg-29349

just wanted to point out that youtube uses apache and sends all requests 
through fast-cgi to a wsgi compliant python app-server.  no apach+php 
there.

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,28783,60627#msg-60627