The difference between CGI, FastCGI, PHP-CGI and PHP-FPM

CGI

The full name of CGI is "Common Gateway Interface". It is a tool that the HTTP server uses to "talk" to programs on your or other machines. The program must run on the network server.

CGI can be written in any language as long as the language has standard input, output and environment variables. Such as php, perl, tcl, etc.

FastCGI

FastCGI is like a long-live CGI. It can be executed all the time. As long as it is activated, it will not take time to fork every time (this is the most popular CGI). The criticized fork-and-execute pattern). It also supports distributed computing, that is, FastCGI programs can be executed on hosts other than the website server and accept requests from other website servers.

FastCGI is a language-independent, scalable architecture CGI open extension. Its main behavior is to keep the CGI interpreter process in memory and thus obtain higher performance. As we all know, repeated loading of the CGI interpreter is the main reason for low CGI performance. If the CGI interpreter remains in memory and accepts FastCGI process manager scheduling, it can provide good performance, scalability, Fail-Over features, etc.

FastCGI Features

FastCGI is language independent.

FastCGI is an in-process application that runs independently of the core web server, providing a more secure environment than APIs. APIs link an application's code with the core web server, meaning an application with the wrong API could break other applications or the core server. Malicious API application code can even steal the keys of another application or core server.

FastCGI technology currently supports languages: C/C++, Java, Perl, Tcl, Python, SmallTalk, Ruby, etc. Related modules are also available on popular servers such as Apache, ISS, Lighttpd, etc.

FastCGI does not depend on the internal architecture of any web server, so even if server technology changes, FastCGI remains stable.

How FastCGI works

The FastCGI process manager (IIS ISAPI or Apache Module) is loaded when the Web Server starts up

The FastCGI process manager initializes itself and starts multiple CGI interpreter processes (visible multiple php- cgi) and wait for the connection from the Web Server.

When a client request reaches the Web Server, the FastCGI Process Manager selects and connects to a CGI interpreter. The web server sends CGI environment variables and standard input to the FastCGI subprocess php-cgi.

After the FastCGI sub-process completes processing, it returns standard output and error information to the Web Server from the same connection. When the FastCGI child process closes the connection, the request is processed. The FastCGI child process then waits for and handles the next connection from the FastCGI process manager (running in the Web Server). In CGI mode, php-cgi exits at this point.

In the above case, you can imagine how slow CGI usually is. Every web request to PHP must reparse php.ini, reload all extensions and reinitialize all data structures. With FastCGI, all of this happens only once, when the process starts. An added bonus is that persistent database connections work.

Disadvantages of FastCGI

Because it is multi-process, it consumes more server memory than CGI multi-threading. The PHP-CGI interpreter consumes 7 to 25 megabytes of memory per process. Multiply this number by 50 or 100. A large amount of memory.

Nginx 0.8.46+PHP 5.2.14 (FastCGI) server has 30,000 concurrent connections. The 10 Nginx processes started consume 150M memory (15M*10=150M), and the 64 php-cgi processes started consume 1280M memory. (20M*64=1280M), plus the memory consumed by the system itself, the total memory consumption is less than 2GB. If the server memory is small, you can only open 25 php-cgi processes, so that the total memory consumed by php-cgi is only 500M.

The above data is excerpted from Nginx 0.8.x + PHP 5.2.13 (FastCGI) to build a web server that is ten times better than Apache (version 6)

PHP-CGI

PHP-CGI comes with PHP FastCGI manager.

Disadvantages of PHP-CGI:

php-cgi needs to restart php-cgi after changing the php.ini configuration to make the new php-ini take effect, and smooth restart is not possible.

Kill the php-cgi process directly, and php will not be able to run. (PHP-FPM and Spawn-FCGI do not have this problem, the daemon process will smoothly regenerate new child processes.)

PHP-FPM

PHP-FPM is a PHP FastCGI manager, only used for PHP Yes, it can be downloaded at http://php-fpm.org/download.

PHP-FPM is actually a patch of the PHP source code, aiming to integrate FastCGI process management into the PHP package. It must be patched into your PHP source code, and it can be used after compiling and installing PHP.

Now we can download the branch that directly integrates PHP-FPM in the source tree of the latest PHP 5.3.2. It is said that the next version will be integrated into the main branch of PHP. Compared with Spawn-FCGI, PHP-FPM has better CPU and memory control, and the former is easy to crash and must be monitored with crontab, while PHP-FPM does not have such troubles.

PHP5.3.3 has integrated php-fpm and is no longer a third-party package. PHP-FPM provides a better PHP process management method, which can effectively control memory and processes, and can smoothly reload PHP configuration. It has more advantages than spawn-fcgi, so it is officially included in PHP. PHP-FPM can be turned on by passing the –enable-fpm parameter in ./configure.

Spawn-FCGI

Spawn-FCGI is a general FastCGI management server. It is part of lighttpd. Many people use Lighttpd's Spawn-FCGI for management work in FastCGI mode, but there are Few shortcomings. The emergence of PHP-FPM has somewhat alleviated some problems, but PHP-FPM has the disadvantage of having to recompile, which may pose a considerable risk (refer) to some already running environments. It can be used directly in PHP 5.3.3 PHP-FPM.

Spawn-FCGI has now become a separate project, which is more stable and brings convenience to the configuration of many Web sites. Many sites have paired it with nginx to solve dynamic web pages.

The latest lighttpd does not include this piece (http://www.lighttpd.net/search?q=Spawn-FCGI), but it can be found in previous versions. It is included in the lighttpd-1.4.15 version (http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz). The current download address of Spawn-FCGI is http://redmine.lighttpd .net/projects/spawn-fcgi, the latest version is http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz.

Note: For the latest Spawn-FCGI, you can search for "Spawn-FCGI" on the lighttpd.net website to find its latest version release address.

Comparison between PHP-FPM and spawn-CGI

PHP-FPM is very convenient to use. The configuration is in the PHP-FPM.ini file, and startup and restart can be done from php/sbin/PHP-FPM in progress. What is more convenient is that after modifying php.ini, you can directly use PHP-FPM reload to load it. You can complete the modification and loading of php.ini without killing the process. The results show that using PHP-FPM can significantly improve the performance of PHP. The CPU recycling speed of the process controlled by PHP-FPM is relatively slow, and the memory is allocated evenly.

The CPU of the process controlled by Spawn-FCGI drops quickly, and the memory allocation is uneven. There are many processes that appear to be unallocated, while others are highly occupied. It may be caused by uneven distribution of process tasks. This also leads to a decrease in overall response speed. The reasonable distribution of PHP-FPM leads to the mention of overall response and the average of tasks.