Great news. This makes it significantly easier to get PHP running on Nginx.

Fortunately, it was never hard.

  Before (5.3.x):
  tar xjvf php-5.3.2.tar.bz2
  cd php-5.3.2
  svn co http://svn.php.net/repository/php/php-src/trunk/sapi/fpm sapi/fpm
  ./buildconf --force
  ./configure --enable-fpm ...
  make
  sudo checkinstall -D make install

  After (5.3.x):
  tar xjvf php-5.3.3.tar.bz2
  cd php-5.3.3
  ./configure --enable-fpm ...
  make
  sudo checkinstall -D make install

  Before (< 5.3.x):
  tar xjvf php-5.2.13.tar.bz2
  wget php-fpm.org/downloads/php-5.2.13-fpm-0.5.14.diff.gz
  gzip -cd php-5.2.13-fpm-0.5.14.diff.gz | patch -d php-5.2.13 -p1
  cd php-5.2.13
  ./configure --enable-fastcgi --enable-fpm ...
  make
  sudo checkinstall -D make install

  After (< 5.3.x):
  PHP 5.2.x is no longer supported. Stop using it.

nginx's configuration is the same for all.

Eh, the main difference to me is that now it is part of the official source, it will likely be included in package manager builds on major Linux distros, instead of having to compile from source at all.

PHP has had a fastcgi implementation for ages, but this adds process management to it.

Can someone explain this to me?

PHP's two most popular SAPIs are embedded and FastCGI. mod_php is embedded inside of Apache (and is problematic), whereas the FastCGI SAPI communicates via TCP or a Unix socket. The two major (there may be others) FastCGI process managers are spawn-fcgi (a Lighttpd subproject, http://redmine.lighttpd.net/projects/spawn-fcgi/wiki) and PHP-FPM. The latter is quite stable and has some nifty features (http://php-fpm.org/).

PHP-FPM used to exist as a patch for PHP (http://php-fpm.org/downloads/). It's now in core, and can be built with the --enable-fpm configure flag.

What's "problematic" about mod_php? It's got to be one of the more widely used bits of software out there. Like anything, I'm sure there are tradeoffs involved, but perhaps it's better to be a bit more explicit about what they are rather than stopping at "problematic"?

I've had a couple problems but I wouldn't call it problematic:

1) When you select mod_php/the Apache SAPI, certain functions get disabled like chroot() and pcntl_fork() since they're not safe to be used under Apache. This is annoying when you have some backend scripts that need those functions.

2) If you run PHP with all the popular plugins, you're looking at about 15MB per Apache process/thread. @256 active clients that's almost 4GB of RAM. Insane, especially considering it's loaded in memory whether or not the requested resource is PHP or not.

I recently switched to Nginx+FastCGI and I'm very happy with the speed and memory usage. FPM makes it even better.

For 2, wouldn't most of that memory be either COW or physically shared, read-only? It's been about a year and a half since I've operated a large PHP site, but I don't recall the apache workers getting anywhere close to 15MB each, unless a request was operating on a larger than normal dataset. (this site used curl, gd, memcache, uuid, pspell, tidy, soap, and probably some others I've forgotten, loaded dynamically.)

How much memory does each FCGI process take up, just out of curiosity? You still need 256 of them to deal with that many concurrent connections.

I run bare php FCGI processes that use 4.5MB of memory and use dl() to load the extra libs on demand now.

I wonder if this solves the problem I've had of having a single APC cache across php-cgi children with fastcgi. From what I read handing the process management off to PHP would achieve that, is that what this is doing?

Yes (second to last comment):

http://pecl.php.net/bugs/bug.php?id=11988

How have you been managing the php-cgi children?

Oh cool, I have read that post before but must have skipped over it. I tried the hackish method in that last comment before but it gave me problems. At the moment given that it's fairly low load what I was doing I just left the default method in place which doesn't share APC.

Glad I'm not the only one who cares about this, but don't have more information - only the same question.

A bit off the topic, is there any good introductory doc on how apache modules work?

Yep:

http://amzn.com/0132409674

Thanks.

Yes! It's main and biggest news!