FastCgi vs PHP-FPM using Nginx web server

One small correction: the PHP FastCGI SAPI is still available, even on PHP 5.5.x.

[root@zulu1 ~]# /usr/local/php54/bin/php-cgi -v 
PHP 5.4.17 (cgi-fcgi) (built: Jul 18 2013 05:12:07) 
Copyright (c) 1997-2013 The PHP Group 
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

PHP-FPM is much better than the old FastCGI handling of PHP. As of PHP 5.3.3 PHP-FPM is in core and the old FastCGI implementation isn’t available anymore.

My answer was just down voted (after being online for quite some time) and I understand why, so here is a list why PHP-FPM is actually better than the old FastCGI implementation.

First of all, it was known for quite some time that the FastCGI implementation is bad in the PHP community. A page that documents that can be found at https://wiki.php.net/ideas/fastcgiwork where it says:

php-cgi is not useful in production environment without additional “crutches” (e.g. spawn-fcgi from lighttpd distribution or php-fpm patch). This project assumes integration of such “crutches” and extending php-cgi to support for different protocols.

• daemonization (detach, pid file creation, setup environment variables, setuid/setgid/chroot)
• graceful restart
• separate and improve transport layer to allow support for different protocols
• support for SCGI protocol
• support for subset of HTTP protocol
• …

Here is a list of the things that PHP-FPM does better that was taken from http://php-fpm.org/about/:

• PHP daemonization: pid file, log file, setsid(), setuid(), setgid(), chroot()
• Process Management. Ability to “gracefully” stop and start PHP workers without losing any queries. This allows gradually updating the configuration and binary without losing any queries.
• Restricting IP addresses from which requests can come from.
• Dynamic number of processes, depending on the load (adaptive process spawning).
• Starting the workers with different uid/gid/chroot/environment and different php.ini options (no need for safe mode).
• Logging STDOUT and STDERR.
• Ability to emergency restart all the processes in the event of an accidental destruction of the shared memory opcode cache, if using an accelerator.
• Forcing the completion of process if set_time_limit() fails.

Additional features: - Error header - Accelerated upload support - fastcgi_finish_request() - Slowlog with backtrace

On the fastcgi side:

1. Fastcgi is easier to monitor: There is one pid per user in fastcgi. On a web server with many accounts it is easy to find overloaded processes. On the other hand, php-fpm creates many processes depending on the requests + one master process. This is messy when you have lots of connections from different IP.
2. Fastcgi configuration is easier: Fastcgi is included in apache configuration. So it makes things easier. On the other hand, php-fpm requires additional configuration files. If there are configuration dependencies it makes things complicated.
3. The big shared hosting companies still don't use php-fpm in 2015 with php 5.6 Today, all the biggest shared web hosting companies (bluehost,hostgator,namecheap) use fastcgi. I think there are reasons why they don't offer php-fpm as php-handler.

On the php-fpm side:

1. i have noticed that php-fpm consumed 20% less than fastcgi which consumed 20% less than mod_php. So, php-fpm is good for web server with the smallest amount of ram.