Compare the differences between CGI, FastCGI, PHP-CGI and PHP-FPM

CGI

The full name of CGI is "Common Gateway Interface". It is a tool for the HTTP server to "talk" to your program or that of other machines. The program must run on the network. on the 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 criticized fork-and-execute mode of CGI). 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 in-process applications run independently of the core web server, providing a more secure environment than the API . 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

Loads the FastCGI process manager (IIS ISAPI or Apache Module) when the Web Server starts.

The FastCGI process manager initializes itself and starts multiple CGIs Interpreter process (multiple php-cgi visible) and waits for connection from 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. 50 or 100 is a large amount of memory.

Nginx 0.8.46+PHP 5.2.14 (FastCGI) server has 30,000 concurrent connections. The 10 Nginx processes opened consume 150M memory (15M*10=150M), and the 64 php-cgi opened The process consumes 1280M of memory (20M*64=1280M), plus the memory consumed by the system itself, the total consumption is less than 2GB of memory. 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 is the FastCGI manager that comes with PHP.

Disadvantages of PHP-CGI:

After changing the php.ini configuration in php-cgi, you need to restart php-cgi 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. It is only 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 into your PHP source code and 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 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. You can enable PHP-FPM by passing the –enable-fpm parameter in ./configure.

Spawn-FCGI

Spawn-FCGI is a general FastCGI management server, which is part of lighttpd. Many people use Lighttpd's Spawn-FCGI to perform management work in FastCGI mode, but it has many 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/ Performed in sbin/PHP-FPM. 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 make php have a lot of changes. performance improvement. 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 relatively 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.

The above is the detailed content of Compare the differences between CGI, FastCGI, PHP-CGI and PHP-FPM. For more information, please follow other related articles on the PHP Chinese website!