Understand the configuration of max_children in php-fpm

Now nginx fpm has basically become the mainstream configuration, among which we are more concerned about the configuration of pm.max_chindren

First, we pay attention to a setting: pm = static/dynamic.

Related learning recommendations: PHP programming from entry to proficiency

This option is to identify the generation mode of the fpm child process ：

static ： means directly forking out pm.max_chindren worker processes when fpm is running

dynamic: means that start_servers processes will be forked during runtime, and will be dynamically adjusted according to the load, up to no more than max_children processes.

It is generally recommended to use static. The advantage is that it does not need to dynamically determine the load situation and improves performance. The disadvantage is that it takes up more system memory resources.

The above tells us the number of worker processes represented by max_chindren. It is generally believed that the more concurrency this configuration can handle at the same time, this is a relatively big misunderstanding:

• #1) In fact, there are more processes, which increases the cost of process switching, which is more core. Yes, the number of fpm processes that can be executed concurrently will not exceed the number of CPUs. It is a wrong understanding to increase QPS by opening more workers. It does not mean that if you open more processes, you will have more CPUs for processing.
• 2) There are fewer worker processes. If the server is busy, it will cause nginx to hit the data to fpm. It will be found that all workers are working and there are no idle workers to accept requests, thus Resulting in 502.
• 3) In actual business, since we have a lot of I/O operations, such as reading the database, or internal RPC calls, while waiting for I/O, the process will be sleep by the system, and It does not occupy the CPU. If fewer workers are configured, the CPU will not be utilized.

So how should the number of workers be configured?

Theoretically, the number of woker processes = the number of CPUs is the most reasonable, but due to point 2, each worker may not have finished processing the request, so 502 will occur frequently. But opening more processes just means to avoid 502 and temporarily hang the request, but this is only a way to alleviate it. In fact, this will not only increase the concurrency of the system, but also increase the load of the system. Therefore, based on 2 and 3, set a A reasonable number of workers is more important.

The only martial arts in the world that can only be fast is to improve the efficiency of the program as much as possible and compress the time of a single request to the minimum. In this way, the processing time of a single worker is shortened, which can be processed in unit time. Naturally, there were more requests.

Then the number of max_children can be estimated by the number of requests processed by each worker in unit time. If the processing time of the largest request (cpu time in xhprof) is within 100ms, and 100 requests come in at the same time within 100ms, then in theory, 100 worker processes need to be configured to hang the requests first.

However, the maximum request time may be affected by many external circumstances and is difficult to estimate, especially network I/O is also included. We can borrow third-party profile tools, such as xhprof , this type of tool can count CPU time consumption. Calculating the real number of workers through this time is much more reasonable than calculating the total time. In fact, there is a shortcut here to configure your max_children number, which is to set max_childnren in the early stage. into a relatively large value. After running stably for a period of time, observe the max active processes in the status of fpm, and then configure max_children to be larger than it. It will be ok.

The above is the detailed content of Understand the configuration of max_children in php-fpm. For more information, please follow other related articles on the PHP Chinese website!