What's fastcgi?

　　First, what is fastcgi?
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 all know, the repeated loading of CGI interpreters is the main reason for the low performance of CGI, and can provide good performance, scalability, fail-over characteristics, and so on if the CGI interpreter remains in memory and accepts the FASTCGI process Manager schedule.

FastCGI's official site is in http://www.fastcgi.com.

The working principle of fastcgi is:

1. Load the FASTCGI Process Manager (IIS ISAPI or Apache Module) when the Web Server starts;

2. fastcgi the process Manager itself, start multiple CGI interpreter processes (visible in Task Manager Php-cgi.exe) and wait 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.exe.

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 webserver). In the normal CGI mode, Php-cgi.exe quits here.

In the above scenario, you can imagine how slow CGI is usually. Each Web request PHP must reparse php.ini, reload all DLL 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.

　　Why use FASTCGI instead of multithreaded CGI interpreter?
This may be a multifaceted consideration, for example:

1, you can not, in any case, stable use of multithreaded CGI interpreter on Windows platform, whether it is IIS ISAPI method or Apache module method, they always run for a period of time to crash. Is it strange? But it does exist!

Of course, there are many times when you can stabilize the use of multithreaded CGI interpreter, but you may find that the Web page sometimes error, in any case can not find the reason, and the fastcgi way to change the probability of this error will be greatly reduced. I'm not sure why, but I think the CGI interpreter for the standalone address space may eventually be a little bit more stable than the form of the shared address space.

2, Performance! Is it possible that fastcgi is faster than a multithreaded CGI interpreter? But sometimes it does, and only by testing your site can you make a final conclusion. Why, I find it difficult to say, but there is information that in the era of Zend Winenabler, Zend is also recommended to use the Windows platform fastcgi instead of IIS ISAPI or Apache Module, but now Zend does not do this product.

　　Iii. reasons for not using fastcgi
1. Multi-process consumes more server memory than multithreading, the Php-cgi.exe interpreter consumes 7 to 25 megabytes of memory per process, and multiplies this number by 50 or 100 to try.

2, performance. It's true that sometimes the multithreaded CGI interpreter is faster, huh, and sometimes it's stable.