Table of Contents
There are different ways how a web server can handle PHP files. Following are the most common implementations how this is done:
mod_php
“mod_php” is a module for the web-server “Apache”.
With this module PHP is therefore “integrated” into the web-server. So there is no extra PHP-Process which handles the PHP interpretation. Instead everything is handled by the Apache process.
The main advantage for using “mod_php” is performance. Compared to CGI you usually gain 300-500% when changing to mod_php.
Main reason for that is the ability to cache PHP modules, or specifically the configuration which usually (in CGI and FastCGI) has to be parsed on every request.
How do I know, if mod_php is being used?
Since mod_php is a web-server module it needs to be present in the web-server config which looks something like that
LoadModule php7_module modules/mod_php.so
The following entry was located on my Ubuntu server under/etc/apache2/mods-available/php7.4.load
LoadModule php7_module /usr/lib/apache2/modules/libphp7.4.so
Looking at the generated phpinfo()
output you an also detect mod_php via the following entries:
Server API | Apache 2.0 Handler |
Loaded Modules | core mod_so mod_watchdog http_core mod_log_config mod_logio mod_version mod_unixd mod_access_compat mod_alias mod_auth_basic mod_authn_core mod_authn_file mod_authz_core mod_authz_host mod_authz_user mod_autoindex mod_deflate mod_dir mod_env mod_filter mod_mime prefork mod_negotiation mod_php7 mod_reqtimeout mod_setenvif mod_status |
CGI
The “Common Gateway Interface” (short CGI) implementation means, that the web-server starts an extra PHP process for each request. Therefore all PHP modules, the php.ini and all other configuration needs to be loaded and parsed on every request, which is inefficient.
Main advantage for using CGI is the complete separation between the executing web-server Code and the PHP code.
FastCGI
FastCGI is a PHP implementation, which contains the security advantages from CGI but also being efficient like mod_php.
Here we don’t start a new PHP process on every request, instead we use “ready made” PHP interpreter instances which only get the PHP files passed on to be handled.
How do I know, if FastCGI is being used?
There are multiple ways how you can implement FastCGI in the web-server config. One example would be to send all .php request to a lokal PHP-CGI binary:
ScriptAlias /myPHP /home/devguide/php-install-directory
AddHandler cgi-php .php
Action cgi-php /myPHP/php-cgi
So here all .php files requested by the webserver are going to call the PHP-CGI binary located in /home/devguide/php-install-directory/php-cgi
. Usually this binary is being installed when you install the general PHP package but it could also be a separate package.
The phpinfo()
shows you the following for FastCGI:
Server API | CGI/FastCGI |
FPM
The „PHP-FastCGI Process Manager“ (short PHP-FPM) is an alternative to the FastCGI implementation.
Here the main difference is, that there is always a “parallel” PHP-FPM Process which is connected to the web-server process.
For more details on FPM see HERE
Source: https://blog.layershift.com/which-php-mode-apache-vs-cgi-vs-fastcgi/
How do I know, if FPM is being used?
FPM uses its own service to manage the FPM-Pools. Therefore if you can see the running services on your server (e.g. via top or htop) you can pretty easily detect the PHP-FPM service.
The phpinfo()
will show you the following for FPM:
Server API | FPM/FastCGI |
php-fpm | active |