The working principle of fastcgi

1. Load fastcgi process Manager at Web Server startup (IIS ISAPI or Apache Module)

2, the FASTCGI process manager itself initializes, initiates multiple CGI interpreter processes (visible multiple php-cgi) and waits for a connection from the Web server.

3. When a client request arrives at 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.

4. The fastcgi child 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 (running in Web server). In the CGI mode, php-cgi quits here.

In the above scenario, you can imagine how slow CGI is usually. Each Web request PHP must reparse php.ini, reload all extensions, and reinitialize all data structures. With fastcgi, all of these occur only once when the process is started. An additional benefit is that persistent database connections (persistent DB connection) can work.

Lack of fastcgi:

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.