If you search the web for PHP-FPM configurations, you'll find many of the same configurations popping up. They nearly all use the 'dynamic' process manager and all assume you will have one master process for running PHP-FPM configurations. While there's nothing technically wrong with that, there is a better way to run PHP-FPM.
In this blogpost I'll detail:
Why 'dynamic' should not be your default process manager
Why it's better to have multiple PHP-FPM masters
Why you should prefer the 'ondemand' Process Manager instead of 'dynamic'
Most of the copy/paste work on the internet for PHP-FPM have configurations such as the one below.
[pool_name]
...
pm = dynamic
pm.max_children = 5
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200
Most "guides" advocate the use of the 'dynamic' Process Manager ('pm' option in the config), which allows you to choose how many minimum and maximum (spare) processes you have per pool. Many guides however make blind assumptions on what your server specs are and will cause, like in the example above, a minimum of 3 PHP processes running per pool (pm.start_servers = 3). If you're on a low-traffic site, that could very well be overkill. For your server, it looks like this in your processlist.
root 3986 4704 ? Ss 19:04 php-fpm: master process (/etc/php-fpm.conf)
user 3987 4504 ? S 19:04 \_ php-fpm: pool pool_name
user 3987 4504 ? S 19:04 \_ php-fpm: pool pool_name
user 3987 4504 ? 19:04 \_ php-fpm: pool pool_name
Those 3 processes will always be running, whether they're needed or not. Ondemand Process Manager
A far better way to run PHP-FPM pools, but badly documented, would be the 'ondemand' Process Manager. As the name suggests, it does not leave processes lingering, but spawns them as they are needed. The configuration is similar to the above, but simplified.
[pool_name]
...
pm = ondemand
pm.max_children = 5
pm.process_idle_timeout = 10s
pm.max_requests = 200
The 'ondemand' process manager was added since PHP 5.3.8. The config above causes your default processlist to look like this.
root 3986 4704 ? Ss 19:04 php-fpm: master process (/etc/php-fpm.conf)
Only the master process is spawned, there are no pre-forked PHP-FPM processes. Only when processes are needed will they be started, to a maximum of 5 (with the config above, which is defined by pm.max_children). So if there are 2 simultaneous PHP requests going on, the processlist would be:
root 3986 4704 ? Ss 19:04 php-fpm: master process (/etc/php-fpm.conf)
user 3987 4504 ? S 19:04 \_ php-fpm: pool pool_name
user 3987 4504 ? S 19:04 \_ php-fpm: pool pool_name
After the configured timeout in "pm.process_idle_timeout", the process will be stopped again. This does not impact PHP's max_execution_time, because the process manager only considers a process "idle" when it's not serving any request.
If you're working on a high performance PHP setup, the 'ondemand' PM may not be for you. In that case, it's wise to pre-fork your PHP-FPM processes up to the maximum your server can handle. That way, all your processes are ready to serve your requests without needing to be spawned first. However, for 90% of the sites out there, the ondemand PHP-FPM configuration is better than either static or dynamic.
0 Comments
Please log in to leave a comment.