How Fast CGI Works

Http://www.cppblog.com/woaidongmao/archive/2011/06/21/149092.html

What is fastcgi?
FastCGI is a language-independent, extensible architecture for CGI open extensions whose main behavior is to keep the CGI interpreter process in memory and thus achieve high performance. As we all know, the repeated loading of CGI interpreter is the main reason of poor CGI performance, if the CGI interpreter remains in memory and accepts the FASTCGI process manager scheduling, it can provide good performance, scalability, fail-over characteristics and so on.
FastCGI's official site in http://www.fastcgi.com

How the FastCGI works is:

1. When Web server  starts, load the FASTCGI Process Manager (IIS ISAPI or Apache Module, nginx   fastcgi   The server is separate,fastcgi  can have lighttpd  under the  spawan-cgi or  php-fpm  to manage ));
2, the FASTCGI process manager itself initializes, starts multiple CGI interpreter processes   (multiple php-cgi.exe visible in Task Manager) and waits for a connection from the Web server.
3, when a client request arrives at Web server, the FASTCGI process manager selects and connects to a CGI interpreter. WEB server sends CGI environment variables and standard input to the FASTCGI child process Php-cgi.exe.
4. When the fastcgi child process finishes processing, the standard output and error information is returned from the same connection to the Web Server. When the fastcgi child process closes the connection, the request is processed to completion. The fastcgi child process then waits and processes the next connection from the FASTCGI process Manager (running in webserver). In the normal CGI mode, php-cgi.exe exits here.

In the above scenario, you can imagine how slow the CGI is usually. Every Web request PHP must re-parse php.ini, reload all DLL extensions, and initialize all data structures. With fastcgi, all of this occurs only once when the process is started. An additional benefit is that the persistent database connection (persistent connection) can work.

Second, why use fastcgi, rather than multithreaded CGI interpreter?
This may be due to a variety of considerations, such as:
1, you can no matter how stable on the Windows platform using multithreaded CGI interpreter, either IIS ISAPI mode or Apache module mode, they always run for a period of time crashed. Strange, huh? But there is such a situation!
Of course, there are a lot of times you can use the multi-threaded CGI interpreter, however, you may find that the Web page sometimes error, no matter how to find the reason, and in the fastcgi way when the probability of this error will be greatly reduced. I don't know why, I think the CGI interpreter for the standalone address space may eventually be a little bit more stable than the shared address space.
2, Performance! Performance? Is it possible that fastcgi is faster than a multithreaded CGI interpreter? But sometimes it is, only test your site, to conclude. Why, I find it difficult to say, but there is information in the Zend Winenabler era, Zend is also recommended to use the Windows platform under the fastcgi rather than the IIS ISAPI or Apache Module, but now Zend do not do this product.

The technical principle of fastcgi

If you want to understand the technical principles of fastcgi, you need to know what "short-lived applications" are and what is "long-lived applications".

Starting with CGI technology, the following is the theory of CGI: each time a client requests a CGI, the Web server requests the operating system to generate a new CGI process. When the CGI satisfies the requirements, the server kills the process.　　This process is repeated for each request from the server to the client. The theory of fastcgi technology is: Once the FASTCGI program is created, he can continue to work, enough to satisfy the client's request until it is explicitly terminated. If you want to improve the performance of your program through collaborative processing, you can request a Web server to run a copy of multiple fastcgi applications.

CGI is the so-called short-lived application, fastcgi is the so-called long-lived application.

Because the FASTCGI program does not need to constantly generate new processes, it can greatly reduce the pressure on the server. and has high application efficiency.

Since now, the more popular Java language servlet technology has been designed with reference to FASTCGI's technology running.

Features of FastCGI

1. Breaking traditional page processing technology

Traditional page processing technology, the program must be on the same server as the Web server or the application server. This history has been broken by fastcgi technology, FASTCGI technology applications can be installed in the server farm of any one server, and through the TCP/IP protocol and the Web server communication, this is suitable for the development of large distributed Web farms, but also suitable for efficient database control.

2. Clear Request Mode

CGI does not have a clear role, in the FASTCGI program, the program is given a clear role (responder role, authenticator role, filter role).

3. Reasonable program Structure

At first, it really hated the structural requirements of the fastcgi application. It doesn't matter, you will love this structure after a period of writing, only this completely canonical structure can make your program more efficient.

What kind of technology is fastcgi?

Note: I do not know a lot about Lamp,python, this article is my personal understanding, if the error forgot to inform

Since contact with Rubyonrails, fastcgi this technical standard came into my sight, from the technical point of view, the advantages of fastcgi are many, as an alternative to CGI technical standards, FASTCGI has the following advantages (stable, safe, high performance, easy to expand)

• In terms of stability, fastcgi is a separate process pool to run CGI, a single process is dead, the system can easily discard, and then reassign new processes to run the logic.
• From the security perspective, the fastcgi and the host server is completely independent, fastcgi how down will not bring the server down,
• In terms of performance, fastcgi separates the processing of the dynamic logic from the server, and the heavy-duty IO processing is left to the host server, so that the host server can be a single-minded Io, and for a normal dynamic Web page, there may be only a small number of logical processes, A large number of images such as static IO processing do not require the involvement of logic programs (Note 1)
• In terms of extensibility, fastcgi is a neutral technical standard that can be fully supported in any language written processing program (Php,java,python ...).

But what puzzled me is that Apache's support for fastcgi mod_fastcgi is a mess, the latest stable version is still 2003, snap only to 2004, under 1.3 is still barely available, The apache2.0 is reported to be unable to run stably. fastcgi in [lighttpd][] performance is good, but lighttpd in the user base, compatibility is not mainstream (also on Linux performance is good, there is no official version of Windows, There are also bugs under Solaris). In addition FastCGI also lacks the development, lets the person have abandoned the feeling. (This is also true of Ruby's dbi). and other ever-changing technical standards, fastcgi status awkward

It was not until I saw this article that I understood that fastcgi really commiseration. (hehe, the following content is taken from this article)

From the name of the fastcgi is fast CGI, belongs to reformists. Theoretically, he can develop dynamic web with many programming language interfaces, but each of these programming languages is a path of complete revolution. Java camp on their own a set of server standards, to collaborate also directly to Apache or IIS talk, see fastcgi. ASPX direct and IIS are brothers, no fastcgi. The rest of PHP because it is too popular (LAMP), and Apache is an Iron Man, a mod_php on the solution, simple and convenient, Python community cattle people too much, energetic, others engaged in a scgi play, and fastcgi than is more than. By the time rails came out, fastcgi was really senile.

The advent of rails made fastcgi rejuvenated, and Apache began to rebuild the new mod_proxy_fcgi, but its future was not a bright one, and I felt at least a few of the following

• The current fastcgi and server communication is not smart enough, a fastcgi process if the execution time is too long will be treated as a dead process to kill the restart, so it is difficult to handle long-time tasks. This also makes the fastcgi unable to allow online debugging.
• SCGI and other similar technology can be replaced fastcgi, scgi in Python is very successful, full-featured, and now SCGI also started to support rails
• With rails in vogue, an independent mod_rails is possible, and Ruby's own webserver is beginning to emerge, and it is very likely that they will be able to make a connection to the mainstream webserver.fastcgi design when they want to common Gateway Interface (CGI), but the goal now seems to be out of place.

Summary: I think the future of fastcgi is unclear, but for the moment, he is the only tool that rails can enter into the production environment, only to understand how to match it, there is no need for in-depth research.

Note 1: Sometimes the logic will also participate in the generation of images, when the image of the IO processing needs to be involved in the dynamic program, at this time fastcgi technical advantages, although not reflected, but will not be worse than other technical standards.

From:http://www.opbsder.com/html/y2008/1141_fastcgi.html

How Fast CGI Works