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:
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. xkcd: Duty Calls I guess.
Best regards,
Grzegorz N.
Nosek,
That cartoon was great! Thanks for injecting some realistic humor into
the mix.
All the best,
Todd
Posted at Nginx Forum:
On Tue, Dec 08, 2009 at 05:13:24PM -0800, Michael S. 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 S.
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
[email protected] mailto:[email protected]
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 O. 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 N.
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:
Igor S. 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
[email protected] mailto:[email protected]
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 Wed, Dec 9, 2009 at 1:09 AM, Phillip O. [email protected]
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.
Grzegorz N. 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:08 AM, Phillip O. [email protected]
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:
On Wed, Dec 9, 2009 at 4:24 AM, miradev [email protected] 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 S. 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 S.
http://sysoev.ru/en/
On 12/9/09 7:39 AM, “Michael S.” [email protected] 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 A.
On Wed, Dec 9, 2009 at 1:01 AM, Igor S. [email protected] 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 7:51 AM, Akins, Brian [email protected]
wrote:
On 12/9/09 7:39 AM, “Michael S.” [email protected] 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…
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: