Question PHP-FPM max_children config doesn't seem to have an effect on performance

[Lee990]

Server operating system version

Centos 7

Plesk version and microupdate number

18.0.35 Obsidian

Hello. I have a server with 8 core and 8 Gigs of RAM. I am currently trying to achieve a better concurrency.
The server is used for a simple REST API : select data from db and echo as JSON result. One request under normal load should take less than 300ms.

In attempt to achieve better concurrency, have tried to use PHP-FPM with the configuration below.


I have increased max_children from 10 to 207. I put 32MB for maximum memory, which means it will use up around 6.6 Gigs of my RAM. After applying that config, I can see PHP FPM children being created in processes. But it seems to have no effect on performance. I confirmed this by using Apache Jmetter to send 100 requests with 1 second ram-up period. If I look at my RAM and CPU usage, they all stay the same even when I send those requests, no significant spikes even if I tried 1000 requests under 20 seconds.

And most importantly, whether I pick 10 or 207 for pm.max_children it has no effect on concurrency.

Can someone help me with this? am I missing something that PHP FPM config is not working properly?

 

[Bitpalast]

The max_children setting defines, how many concurrent active processes can be handled for the domain instance. If you set this to e.g. 10 and all 10 PHP-FPM instances are busy at the moment when the 11th request comes in, that additional request cannot be processed. The requestor will wait for a while, then eventually time out as if the server was unresponsive (which it actually is in that situation). However, setting a very high number is no good either, because then you risk that many long running processes are created that are consuming a lot of CPU, so the time for other tasks will become very limited. 8 cores and only 8 GB of RAM in this scenario are guaranteed to crash the server when long runnin requests are made. It might have worked on your tests, because the test sequence may not have put a lot of load on the system.

Itt is generally a good idea to limit the number of children to a decent number like say 30 (which is actually a lot), then allow each child to have a few thousand processes before it is recycled. Normally, a PHP request should be processed within milliseconds, so a low number of children will cause no problems. Only if you have many long running processes you need more children, but your server is way to weak for such a scenario. In that case it will be better to analyze the coe why it is taking so long for execution and to fix it.

Also, if I got you right, you are asking whether the number of max_children influences peformance. More children mean more administrative work for the system for switching between them. Idle children won't help performance either. But a too small number along with long running scripts will block server responses. So there is no general rule. You need to find the sweet spot for your specific case. That will most likely not be up high like 207, but rather something like 10 or 20.

 

[Lee990]

The max_children setting defines, how many concurrent active processes can be handled for the domain instance. If you set this to e.g. 10 and all 10 PHP-FPM instances are busy at the moment when the 11th request comes in, that additional request cannot be processed. The requestor will wait for a while, then eventually time out as if the server was unresponsive (which it actually is in that situation). However, setting a very high number is no good either, because then you risk that many long running processes are created that are consuming a lot of CPU, so the time for other tasks will become very limited. 8 cores and only 8 GB of RAM in this scenario are guaranteed to crash the server when long runnin requests are made. It might have worked on your tests, because the test sequence may not have put a lot of load on the system.

Itt is generally a good idea to limit the number of children to a decent number like say 30 (which is actually a lot), then allow each child to have a few thousand processes before it is recycled. Normally, a PHP request should be processed within milliseconds, so a low number of children will cause no problems. Only if you have many long running processes you need more children, but your server is way to weak for such a scenario. In that case it will be better to analyze the coe why it is taking so long for execution and to fix it.

Also, if I got you right, you are asking whether the number of max_children influences peformance. More children mean more administrative work for the system for switching between them. Idle children won't help performance either. But a too small number along with long running scripts will block server responses. So there is no general rule. You need to find the sweet spot for your specific case. That will most likely not be up high like 207, but rather something like 10 or 20.

Thanks for the reply, my mistake. I understand max_children better now t hanks to your explanation.
I set it to 20 and configured Apache+Nginx instead, my rest api works faster now and can handle more concurrency.