Some misunderstandings about max_chin.pdf of php-fpm

Some misunderstandings about max_chin.pdf of php-fpm

At present, nginx + fpm is basically the mainstream configuration, among which we are more concerned with the configuration of pm. max_chin.pdf

First, let's focus on a prerequisite: pm = static/dynamic,

This option identifies the generation mode of the fpm sub-process:

Static: indicates that a worker process in pm. max_chin.pdf is directly fork when fpm is running,

Dynamic: indicates that the running fork generates start_servers processes. With the load, it dynamically adjusts to a maximum of max_children processes.

Static is generally recommended. The advantage is that you do not need to dynamically judge the load and improve the performance. The disadvantage is that you need to use more system memory resources.

The preceding figure shows the number of worker processes represented by max_chin.pdf. It is generally believed that the more concurrent this configuration can be processed at the same time, this is a big misunderstanding:

1) Check the source code of fpm. The management process and worker Process communicate data through pipe. As a result, when there are more processes, the overhead of process management is increased, and the overhead of system process switching is increased. What's more important is that the number of fpm processes that can be concurrently executed will not exceed the number of CPUs. It is wrong to increase the qps by enabling the number of worker instances. It does not mean that if you open several more processes, you will have several CPUs to handle them.

2) but the worker process is less open. If the server is busy, it will be directed to nginx to hit fpm, And it will find that all wokers are working, there is no idle worker to accept the request, resulting in 502.

How can I configure the number of workers?

Theoretically, the number of woker processes = the number of CPUs is the most reasonable, but due to the 2nd point reason, each worker may not have processed the request, so that it will frequently be 502. But if you open more requests, you just want to avoid 502 and temporarily put the request hang in place. But this is only a relief. In fact, this will not only increase the system concurrency, but also increase the system load. Therefore, it is important to set a reasonable number of workers.

The world's martial arts, only fast, only to improve program efficiency as much as possible, the time of a single request is compressed to the lowest, so that the processing time of a single worker is shorter, then there will naturally be more requests that can be processed per unit of time.

You can estimate the number of max_children requests processed by each worker per unit time. If the maximum request processing time is within 100 ms, and 100 requests are sent within ms at the same time, we need to configure worker processes theoretically, first, send the request to hang.

However, the maximum request time may be affected by many external conditions, which is not well estimated. In fact, there is a shortcut to configure your max_children count, that is, you first set max_childnren to a relatively large value in the early stage. After running stably for a period of time, observe the max active processes in the fpm status, then, we can configure max_children to be bigger than him.

I hope these articles will help you.

LAMP-PHP-fpm Server Configuration

Ubuntu 14.04 LTS install LNMP Nginx \ PHP5 (PHP-FPM) \ MySQL

High Load PHP-FPM Tuning

Nginx php-fpm 502 solutions and tuning experience

Nginx + PHP-FPM implementation on two servers

Configure nginx + php-fpm mode in Ubuntu 10.04

Nginx & PHP-FPM configuration and optimization Guide (I)

This article permanently updates the link address: