This looks particularly interesting. I googled it and found http://php-fpm.org/ . I didn't previously realize that a fastcgi implementation had been merged into PHP core. Sweet!
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.
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'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.)
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?
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.
The backwards compatibility break they did got me thinking, it would be great to see a major PHP release that broke backwards compatibility to get things right as Python have done with version 3. I think anyone not interested in porting their code would already have a PHP more than suitable for their needs.
I just mean the little niggling things people complain about like all the functions in the global namespace, inconsistent arguments, inconsistent error handling. I guess though a lot of PHP support comes from the deploy everywhere make minimal changes to old code ideas, so I can see why their quiet happy to not want to break to much old code.
Actually, I agree. I have often thought there is a space for a revamped PHP, with compatible syntax (because people know it) but with many of the niggles removed and a better core library.
Accessible core libraries that are people are encouraged to use, stuff without a mess of dependencies to. You hardly ever seen introductions to PHP that encourage library use, it's mostly about rolling your own stuff.
This looks particularly interesting. I googled it and found http://php-fpm.org/ . I didn't previously realize that a fastcgi implementation had been merged into PHP core. Sweet!