JIYIK CN >

In "First Contact with CGI", we mentioned the operating mechanisms of CGI and Server APIs, as well as their respective advantages and disadvantages. In this chapter, we will learn about FastCGI, which combines the advantages of CGI and Server APIs.

A brief introduction to FastCGI

Compared with CGI, FastCGI is different from it in two aspects. The first point is that the FastCGI process is permanent, that is, the process used to handle the request will not exit with the end of the request, but continue to run and wait for new requests to be processed. This solves the performance problem caused by the frequent creation and closing of CGI processes; the second point is that the communication method between FastCGI and the web server is different from that of CGI. When the FastCGI application and the web server are on the same machine, FastCGI and the web server communicate using a full-duplex connection, and the environment information, input information, output and error information are all transmitted through this full-duplex connection. CGI communicates through environment variables, stdin, stdout, stderr and other files. If the FastCGI application and the web server are on different machines, the two parties communicate through sockets (that is, TCP connections).

The above two points are the differences between FastCGI and CGI, and they are also the advantages of FastCGI. In addition, the other advantages of FastCGI are the same as those of CGI, such as simple implementation, independence from development language, process independence, and no influence from the internal architecture of the web server.

Combining the above two points, let's look at the process of a complete request

Application of FastCGI in PHP

After PHP 5.3, PHP-FPM is integrated into PHP, which implements the application of FastCGI in PHP. For the specific application of FPM, please refer to the article "What does FPM in PHP do?" . Here we only explain the first point above, the permanence of the FastCGI process.

First we need to configure PHP-FPM (open the configuration file php installation directory /etc/php-fpm.conf). After opening the file, find pm and pm.start_servers and configure them as follows

pm = dynamic //The process will be created only when there is a request for connection
pm.start_servers = 2 //The number of child processes of FastCGI enabled

When we start the FPM service, the system creates a FastCGI main process, and then the main process creates two child processes

# ps –ef | grep php-fpm //View all fpm process information
root 6116 1 0 13:24 ? 00:00:00 php-fpm: master process (/usr/local/php5/etc/php-fpm.conf)
nobody 6117 6116 0 13:24 ? 00:00:00 php-fpm: pool www          
nobody 6118 6116 0 13:24 ? 00:00:00 php-fpm: pool www

We will see three process information. When we use the above command again after a period of time, we will find that these three information are still there. So the FastCGI process is permanent.

Of course, since the FastCGI process is permanent, if there is no request for the Web service, but the process is still occupying resources, it would be a waste of resources for the server. This is indeed the case, but PHP-FPM has taken this into consideration when designing it. When configuring it, you can set the pm option to ondemand, which means that no child process will be created when the FPM service is started, and only when a connection is requested will a child process be created.

Set the following in the configuration file

pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 10s //This option is only valid when pm is set to ondemand, which means that after the child process has processed the request, it will continue to wait for new requests. If there is no new request for more than 10 seconds, the process will exit and release resources.

After the configuration file is changed, restart the FPM service. At this time, we check the process information and there is only one piece of information.

#ps –ef | grep php-fpm
root 6415 1 0 13:38 ? 00:00:00 php-fpm: master process (/usr/local/php5/etc/php-fpm.conf)

At this point there is only the main process created by the system, and then we can make a request (for example: http://localhost/index.php).

Then we check the process information again

# ps –ef | grep php-fpm
root 6415 1 0 13:38 ? 00:00:00 php-fpm: master process (/usr/local/php5/etc/php-fpm.conf)
nobody 6485 6415 0 13:42 ? 00:00:00 php-fpm: pool www

At this time, there will be two process information, in addition to the main process, there is also a sub-process that handles the request. Then we do not send a request for 10 seconds, and then we check the process information again after 10 seconds

#ps –ef | grep php-fpm
root 6415 1 0 13:38 ? 00:00:00 php-fpm: master process (/usr/local/php5/etc/php-fpm.conf)

At this time, it becomes a main process information. Of course, this main process will not exit. As long as the service is turned on, it will always exist and listen to a certain port to see if there are new requests. It is the same as the Web server process. The process will only be killed when the service is turned off.

The above case of closing the child process seems to be inconsistent with the FastCGI specification. It is true that the FastCGI specification stipulates that the process is permanent, but when pm is set to dynamic or static, the process does exist all the time. However, if there is no request, it is also a waste of computer resources. Therefore, we can set its waiting time, and the main process will kill the child process after this time. Of course, we can set this time longer according to the actual situation, and if our application is frequently accessed, the process will always exist, so this does not violate the FastCGI specification.

Since the FastCGI program and the Web server communicate through a TCP connection, the FastCGI program and the Web server can be deployed on different machines. This facilitates our future expansion and distributed deployment, making it easy to achieve load balancing.

Briefly describe whether FastCGI programs are single-threaded or multi-threaded

The FastCGI mechanism allows developers to freely choose between single-threaded and multi-threaded methods. There are two ways to implement multi-threaded programs:

1. The program can accept multiple connections from the Web server through multi-threading to receive concurrent requests

Second, through the multiplexed connection form, concurrent requests are sent to multiple threads of the program through one connection for processing.

Of course, since thread safety issues need to be considered during the development process, and multi-threaded program testing and debugging are also difficult, most developers still prefer to use a single-threaded mode. For single-threaded programs, multiple requests can also be received in the form of multiplexed web connections, but the processing method is event-driven (for event-driven, you can refer to the article "My Understanding of Event-Loop"
to understand its principle). Whether to use single-thread or multi-thread should be decided based on the actual situation and developer habits (this sentence is a bit redundant).

The above is my general introduction to FastCGI. Due to my limited level, I can only understand it to this depth. You are welcome to leave a message below to give good suggestions.