Differences and dis/advanages between: Fast-CGI, CGI, Mod-PHP, SuPHP, PHP-FPM
Solution 1:
CGI and FastCGI are two protocols not specific to PHP:
-
CGI scripts is a way how to run a server side script (not only PHP!) when a HTTP request arrives. In this setup, the web server launches a new CGI process for every incoming request, causing significant performance overhead.
-
FastCGI is a "better CGI" - to address the limitations of CGI, the FastCGI runs as a server (TCP or UNIX), so that resources can be reused across requests.
PHP-enabled webserver can be configured as following:
-
mod_php is an Apache module to run PHP. In this setup, PHP request is handled under Apache process with everything that goes with it: PHP processes are defined in Apache configuration, PHP runs under Apache user and permissions etc.
-
PHP-FPM is PHP's FastCGI implementation. In this setup, PHP-FPM runs as a standalone FastCGI server and Apache connects to it using FastCGI modules, such as
mod_fcgid
,mod_fastcgi
ormod_proxy_fcgi
(Apache 2.4+). In this configuration, permissions, processes related stuff & everything else is controlled by the PHP-FPM server. Performance is comparable withmod_php
. -
SuPHP - this was used to address some shortcomings of
mod_php
related to permissions: withmod_php
PHP scripts are run under the Apache user/group, butmod_suphp
can run the scripts as a different user. suPHP is not maintained anymore and should not be used. -
CGI/FastCGI - I have added this one based on a question in the comments. Without knowing the details of the setup, PHP can be run as FastCGI server using any other FastCGI implementation - as explained in another question. I don't use this setup and don't see any benefit over PHP-FPM.
-
CGI - PHP can also be run as the good-ol' CGI script, but I can't imagine a single good use case for that, apart for compatibility with some very outdated environments.
Regarding advantages and disadvantages of those different approaches, I stick only to mod_php
and PHP-FPM, covering two main use cases:
-
mod_php
can be useful in certain Docker setups where you want to deliver a single container running a PHP-enabled web server. The fact that everything runs as a single process makes the Docker container configuration easier. On the other hand, running PHP-FPM server in a single container with a webserver would require process orchestration either with supervisord, advanced bash scripting or some other approach and goes against best practices writing Docker containers. -
PHP-FPM is a more powerful approach that separates the concerns better, so the PHP-FPM server can be configured, (performance-)tuned and maintained separately from the webserver. This also allows to run the PHP-FPM server in a pool or on a different machine than the webserver. As implied above, for Docker containers, a separate PHP-FPM and webserver containers are recommended in this case, making the configuration more complex (and more powerful). PHP-FPM approach is also the only way with nginx webserver as the PHP module for it AFAIK does not exist.
My Docker implementation of the two aforementioned approaches can be found here:
- https://gitlab.com/craynic.com/docker/lap/ - a single container approach, running PHP 7.4/8.0 as an Apache module
- https://gitlab.com/craynic.com/craynic.net/mvh - a multi container approach, separating PHP-FPM from Apache webserver
The implementation is designed to work with some of my legacy and new projects in my Kubernetes cluster. Feel free to use it.
So, TLDR:
- CGI, FastCGI are protocols; CGI is slow, FastCGI is much faster
-
mod_php
and PHP-FPM are two main ways how to run PHP -
mod_SuPHP
was an approach that was used to addressmod_php
shortcomings. It is outdated and PHP-FPM should be used instead.