The relationship between CGI, FastCGI and PHP-FPM

Selected from: https://www.cnblogs.com/kenshinobiy/p/7470635.html
1) CGI
The CGI full name "Public Gateway Interface" (Common Gateway Interface) is an interface for HTTP servers to communicate with programs on other machines, and its programs must run on a network server.
NOTE:CGI can be written in any language, as long as the language has standard input, output, and environment variables.

2) FastCGI
FastCGI is a resident CGI, it can always execute, as long as the activation, will not take time to fork every time (this is the most criticized CGI fork-and-execute mode). It also supports distributed operations, where the FastCGI program can execute on a host other than the Web server and accept requests from other Web servers.
The fastcgi is a language-independent, scalable, CGI-open extension that primarily acts to keep the CGI interpreter process in memory and thus achieve higher performance. As we know, the repeated loading of the CGI interpreter is the main reason for the low performance of CGI, and if the CGI interpreter is stored in memory and accepts the FASTCGI process Manager schedule, it can provide good performance, scalability, and so on.
Advantages:
1. fastcgi has language independence;
2. FastCGI is run independently of the core Web server, providing a more secure environment than the API. APIs link application code to the core Web server, which means that an application in the wrong API could damage other applications or core servers. The malicious API's application code can even steal a key from another application or core server;
3. The fastcgi technology currently supports languages: C + +, Java, Perl, TCL, Python, SmallTalk, Ruby, and so on. Related modules are also available on popular servers such as Apache, ISS, and lighttpd;
4. FastCGI does not depend on the internal architecture of any Web server, so the fastcgi remains stable even if the server technology changes;

Disadvantages:
Because it is a multiple process, it consumes more server memory than CGI multithreading, and the PHP-CGI interpreter consumes 7 to 25 megabytes per process, multiplying this number by 50 or 100 is a large amount of memory.
The Nginx 0.8.46+php 5.2.14 (FastCGI) server consumes 150M of memory (Nginx) with 10 15m*10=150m processes on 30,000 concurrent connections, and 64 php-cgi processes that open consume 1280M of memory (20m*64= 1280M), combined with the memory consumed by the system itself, consumes less than 2GB memory. If the server memory is small, you can simply turn on 25 php-cgi processes so that the total amount of memory consumed by php-cgi is 500M.
The above data is excerpted from Nginx 0.8.x + PHP 5.2.13 (FastCGI) to build a Web server 10 times times better than Apache (6th edition).

Principle:
1. When the Web server is started, load the fastcgi process manager;
2. FASTCGI Process Manager initialization, launching multiple CGI interpreter processes (php-cgi) and waiting for connections from the Web server;
3. When the client request arrives at the Web server, the FASTCGI process manager chooses and connects to a CGI interpreter, which sends the CGI environment variables and standard input to the fastcgi subprocess php-cgi.
4. The fastcgi process completes processing and returns standard output and error information from the same connection to the Web server. When the fastcgi child process closes the connection, the request is processed. The fastcgi process then waits and processes the next connection from the FASTCGI process Manager, which is running on the Web server. In the CGI model, php-cgi quits.
In the above scenario, you can imagine how slow CGI is usually, and every Web request PHP must reparse php.ini, reload all extensions, and reinitialize all of the data structures. With fastcgi, all of these occur only once when the process is started. In addition, database persistent connections can work.

Note:
The main advantage of fastcgi is the separation of the dynamic language and HTTP server, so nginx and PHP/PHP-FPM are often deployed on different servers to share the pressure of the front-end Nginx server, so that the nginx single-minded processing of static requests and forwarding dynamic requests, while PHP The/PHP-FPM server is dedicated to parsing PHP dynamic requests.

3) php-cgi
PHP-CGI is the fastcgi Manager with PHP.
Lack of php-cgi:
1. php-cgi change php.ini configuration after the need to restart php-cgi to make the new Php-ini effective, can not smooth reboot.
2. Directly kill the php-cgi process, PHP will not run (PHP-FPM and spawn-fcgi do not have this problem, the daemon will smooth regeneration of the new child process).

4) spawn-fcgi
SPAWN-FCGI is a common fastcgi Management Server, it is a part of the LIGHTTPD, many people use LIGHTTPD spawn-fcgi mode of management work, but there are a lot of shortcomings. and PHP-FPM to alleviate some of the problems, but PHP-FPM has a drawback is to recompile, which for some already running environment may have a small risk (refer), in the PHP 5.3.3 can directly use PHP-FPM.

SPAWN-FCGI has now become a single project, more stable, but also to many Web site configuration to bring convenience. There are already a number of sites to match it with Nginx to solve dynamic Web pages. The latest lighttpd also does not include this piece (Http://www.lighttpd.NET/search?q=Spawn-FCGI), but it can be found in previous versions. Included in the lighttpd-1.4.15 version (http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz), the current spawn-fcgi download address 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: The latest spawn-fcgi can go to the Lighttpd.net Web site to search "spawn-fcgi" to find its latest version of the release address.

5) contrasting php-fpm and spawn-fcgi
PHP-FPM is very convenient to use, the configuration is in the Php-fpm.ini file, and start, restart can be carried out from the PHP/SBIN/PHP-FPM. It is more convenient to modify the php.ini can be used directly after the PHP-FPM reload loading, without killing the process can be completed php.ini modified loading.
The results show that using PHP-FPM can make PHP a little more performance-enhancing. PHP-FPM-controlled process CPU recovery is slow, memory allocation is very uniform.
SPAWN-FCGI-controlled processes have a fast CPU drop, while memory allocations are unevenly distributed. There are many processes that do not seem to be allocated, while others occupy a high number of them. may be caused by uneven allocation of process tasks. This also leads to a decline in the overall response rate. and PHP-FPM reasonable distribution, resulting in the overall response to the reference as well as the average task.