The max_children setting limits the maximum number of simultaneously executing PHP requests an app is allowed to have. As a separate PHP process is required for each concurrently executing PHP request and each PHP process is a "child" of PHP FastCGI Process Manager (PHP-FPM), the setting is called max_children.
When an app hits its max_children limit, subsequent requests are not accepted by PHP-FPM until one of the app's currently executing requests is completed.
PHP memory usage is proportional to the number of concurrently executing requests. This is because each additional process consumes additional memory. As a result, the server's memory is usually the limiting factor for the maximum number of PHP requests that can be executing at the same time.
A sudden increase in server memory usage is usually due to an app's code becoming slow, the app receiving a spike in traffic, or a combination of both. For example, an increase in requests to a page with slow MySQL queries can cause each query to run even slower than usual, causing a page that seemed normally to be only a little slow to suddenly be extremely slow. In such a situation, the number of concurrent PHP processes will quickly increase and therefore memory usage will quickly increase.
In some situations, an app hitting its max_children limit can prevent a server from running out of memory. However, in other situations, an app hitting its max_children limit can cause unnecessary downtime not only for that app (e.g. if the server actually had enough resources to support more PHP processes) but can also lead to situations that cause downtime for all apps on the server (e.g. triggering Apache's long-standing bugs in tracking request state).
If a server does not have the memory and CPU resources to handle the incoming requests for the apps on a server, slowness and/or downtime will result regardless of whether one is using max_children.
ServerPilot sets max_children to "unlimited". As there is no explicit "unlimited" option for max_children, this is done by setting the value to a very high number that effectively means "unlimited".
For apps created before May 2024, the max_children setting is automatically updated from the prior default (100) to "unlimited" the next time you change the app's PHP version in ServerPilot.
If an app's PHP scripts can't answer requests as quickly as new requests come in, then PHP-FPM (the PHP FastCGI Process Manager) will launch additional PHP processes for the app to answer requests in parallel. If requests are still coming in faster than the PHP scripts can answer them, PHP-FPM will continue launching additional PHP processes for the app.
PHP-FPM will stop launching additional PHP processes for the app once the number of PHP processes for the app reaches max_children. As additional requests keep coming in for the app faster than PHP-FPM will accept them, Apache will queue these additional requests for a period of time until they are accepted by PHP-FPM.
In the vast majority of cases, an app will only reach the max_children limit if there is slow PHP code in the app, so if your app has reached the max_children limit, you need to first fix any slow PHP code.
To look for slow PHP code, you can start by checking the app's PHP slow request log. The PHP slow request log will show you information about requests that took more than five seconds to complete.
Important to note, however, is that the PHP slow request log will only show extremely slow requests (taking longer than five seconds), not generally slow requests (taking up to five seconds). If you don't see much in the PHP slow request log, you should check the app's PHP access log to understand what scripts are being requested and how long they are taking to respond.
If your app does have slow PHP code, you should resolve the slow code issues before increasing the app's max_children setting.
To determine if any of your apps are hitting the max_children limit, SSH in to your server as root and run the following command:
sudo grep max_children /var/log/php?.?-fpm-sp.log.1 /var/log/php?.?-fpm-sp.log
If any of your apps have reached their max_children limit, you'll see output like this:
[24-Apr-2017 19:56:17] WARNING: [pool my-wordpress-app] server reached max_children setting (20), consider raising it
If you don't see any output from the command, then your apps have not hit a max_children limit recently.
The max_children setting is not the number of simultaneous visitors your site can have. Instead, it is the number of simultaneously executing PHP requests. Since site visitors normally only make a request every few seconds and PHP execution time is a small part of the total time it takes a request to complete when there are no slow PHP scripts, the number of visitors your app can have is many, many times larger than the max_children setting of your app.
You can use the following formula to estimate a value of max_children that is sufficient for your app:
max_children = (average PHP script execution time) * (PHP requests per second)
You can estimate how many site visitors you can have for a given max_children setting by knowing your average script execution time and how often a site visitor clicks a link or submits a form.
visitors = max_children * (seconds between page views) / (avg. execution time)
Each visitor to your site clicks one link or submits one form every ten seconds. Each requested PHP script takes 100ms to execute from the time PHP receives the request to the time PHP is done generating the response for the web server server to send back.
100 * 5 / 0.1 = 5,000 ^ ^ ^ | | | | | └ Average request execution time in seconds (0.1s is 100ms) | └ Average seconds between page view for an individual visitor └ max_children setting
So, with a max_children of 100, this app can support up to 5,000 visitors at a time.
From this example, you can see how important fast PHP script execution is. If each PHP request took 2 seconds to execute instead of 0.1 seconds to execute, the app would only be able to support 250 visitors on the site at a time.
The main risk of increasing max_children is that each additional PHP process uses additional memory, so your server needs more memory as you increase max_children.
The amount of memory used by each executing PHP process depends heavily on the app's PHP code. For WordPress apps, this includes the code of the plugins and theme.
If your PHP scripts are very CPU-heavy, your server's CPU load may also go up after increasing an app's max_children setting.
Also, remember that if you have very slow scripts, no setting of max_children will make your site work normally. Increasing max_children when you have slow scripts means, at best, that each request doesn't have to wait for other slow requests to complete before its own slow execution begins. If there are slow scripts, you still need to fix the slow scripts even if you choose to increase max_children.
To increase the max_children setting for an app, SSH in to your server as root and rename this file:
/etc/phpX.Y-sp/fpm-pools.d/APPNAME.d/main.conf
to this:
/etc/phpX.Y-sp/fpm-pools.d/APPNAME.d/main.custom.conf
Next, edit the file and change the value on this line to the maximum number of PHP processes you want the app to be able to have running, for example:
pm.max_children = 100
Finally, restart that PHP version with the command:
sudo service phpX.Y-fpm-sp restart