FastCgi vs PHP-FPM using Nginx web server

jaypabs picture jaypabs · Jun 17, 2013 · Viewed 19k times · Source

I am using this tutorial to install nginx, php and mysql on my new web server.

The tutorial is using ISPConfig 3 and there is an option to whether use FastCgi or PHP-FPM.

I am wondering which is better of the two. In terms of performance and speed, which of the two is the best to use inline with nginx?

BTW, I have also memcached and xcache enabled on my server.

Answer

Fleshgrinder picture Fleshgrinder · Jun 17, 2013

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