CGI
The full name of CGI is “Common Gateway Interface”, A tool for the HTTP server to “talk” with programs on your or other machines. The programs must be run on a network server.
CGI can be written in any language, as long as this language has standard input, output and environment variables. Such as php, perl, tcl, etc.
FastCGI
FastCGI is like a long-live CGI, it can always be executed, as long as it is activated, it will not take time to fork every time (this is the most criticized fork-and-execute mode of CGI). It also supports distributed computing, that is, FastCGI programs can be executed on hosts other than the web server and accept requests from other web servers.
FastCGI is a language-independent, scalable architecture CGI open extension. Its main behavior is to keep the CGI interpreter process in memory and therefore get higher Performance. As we all know, repeated loading of the CGI interpreter is the main reason for the low performance of CGI. If the CGI interpreter is kept in memory and is scheduled by the FastCGI process manager, it can provide good performance, scalability, fail-over features, and so on.
FastCGI features
- FastCGI is language independent.
- FastCGI in-process applications run independently of the core web server, providing a more secure environment than API. APIs link the application code with the core web server, which means that an application with a wrong API may damage other applications or the core server. The application code of a malicious API can even steal the key 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.
- FastCGI does not depend on the internal architecture of any web server, so even if the server technology changes, FastCGI remains stable.
How FastCGI works
- Load the FastCGI process manager (IIS ISAPI or Apache Module)
- The FastCGI process manager initializes itself, starts multiple CGI interpreter processes (multiple php-cgi is visible) and waits for Web Server connection.
- When a client request arrives at the Web Server, the FastCGI process manager selects and connects to a CGI interpreter. The Web server sends the CGI environment variables and standard input to the FastCGI subprocess php-cgi.
- FastCGI subprocess will return the standard output and error information from the same connection to the Web Server after finishing processing. When the FastCGI child process closes the connection, the request is processed. The FastCGI child process then waits and processes the next connection from the FastCGI process manager (running in the Web Server). In CGI mode, php-cgi exits here.
In the above situation, you can imagine how slow CGI is usually. Every web request 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 additional benefit is that persistent database connection (Persistent database connection) can work.
Shortcomings of FastCGI
Because it is multi-process, it consumes more threads than CGI With more server memory, the PHP-CGI interpreter consumes 7 to 25 megabytes of memory per process. Multiplying this number by 50 or 100 is a large amount of memory.
Nginx 0.8.46+PHP 5.2.14 (FastCGI) server with 30,000 concurrent connections, open 10 Nginx processes consume 150M memory (15M* 10=150M), the opened 64 php-cgi processes consume 1280M of memory (20M*64=1280M), plus the memory consumed by the system itself, it consumes less than 2GB of memory in total. If the server memory is small, you can only start 25 php-cgi processes, so that the total memory consumed by php-cgi is only 500M.
The above data is taken from Nginx 0.8.x + PHP 5.2.13 (FastCGI) to build a web server ten times better than Apache (version 6)
PHP-CGI
PHP-CGI is the FastCGI manager that comes with PHP.
PHP-CGI shortcomings:
- php-cgi needs to restart php- after changing php.ini configuration Only cgi can make the new php-ini take effect, and it cannot restart smoothly.
- directly kill the php-cgi process, php will no longer run. (PHP-FPM and Spawn-FCGI do not have this problem, the daemon will smoothly regenerate new child processes.)
PHP-FPM
PHP-FPM is a PHP FastCGI manager, which is only used for PHP and can be downloaded at http://php-fpm.org/download .
PHP-FPM is actually a patch of the PHP source code, designed to integrate FastCGI process management into the PHP package. It must be patched to 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 latest PHP 5.3.2 source tree. It is said that the next version will be integrated into Go to the master branch of PHP. Compared with Spawn-FCGI, PHP-FPM has better control over CPU and memory, and the former is easy to crash and must be monitored with crontab, while PHP-FPM does not have this trouble.
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 by PHP. You can enable PHP-FPM with the –enable-fpm parameter in ./configure.
Spawn-FCGI
Spawn-FCGI is a general FastCGI management server, It is a part of lighttpd. Many people use Spawn-FCGI of Lighttpd for management in FastCGI mode, but there are many shortcomings. The emergence of PHP-FPM has alleviated some problems to some extent, but PHP-FPM has a shortcoming that needs to be recompiled, which may have a lot of risk (refer) for some already running environments. It can be used directly in php 5.3.3 PHP-FPM too.
Spawn-FCGI has become a separate project at present, which is more stable, and it also brings convenience to the configuration of many Web sites. Many sites have used 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 you can Found it in previous versions. (Http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz) is included in the lighttpd-1.4.15 version. 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 the release address of its latest version.
PHP-FPM and spawn-CGI comparison
The use of PHP-FPM is very Convenient, the configuration is in the PHP-FPM.ini file, and the startup and restart can be performed from php/sbin/PHP-FPM. It is more convenient that you can directly use PHP-FPM reload to load after modifying php.ini, and you can complete the modification and loading of php.ini without killing the process. The results show that using PHP-FPM can improve PHP’s performance. The CPU recovery speed of the process controlled by PHP-FPM is relatively slow, and the memory allocation is very uniform. The CPU of the process controlled by Spawn-FCGI drops quickly, and the memory allocation is uneven. Many processes seem to be unallocated, while others are very expensive. It may be caused by uneven distribution of process tasks. This has also led to a decrease in overall response speed. The reasonable allocation of PHP-FPM leads to the mention of the overall response and the average task.