Let’s take a quick look at how best to set up PHP-FPM for high throughput, low latency, and more stable CPU and memory use. By default, most setups have PHP-FPM’s PM (process manager) string set to dynamic and there’s also the common advice to use ondemand if you suffer from available memory issues.
However, let’s compare the two management options based on php.net’s documentation and also compare my favorite for high-traffic setups – static pm:
In This Article
PHP-FPM static vs dynamic vs ondemand
Contents
pm = dynamic – the number of child processes is set dynamically based on the following directives: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand – the processes spawn on-demand (when requested), as opposed to dynamic, where pm.start_servers are started when the service is started.
pm = static – the number of child processes is fixed by pm.max_children.
See the complete list of global php-fpm.conf directives for further details.
PHP-FPM process manager (PM) similarities to CPUFreq Governor
This may seem a bit off-topic, but I hope to tie it back into our PHP-FPM tuning topic. We’ve all had slow CPU issues, whether it be a laptop, VM or dedicated server. Remember CPU frequency scaling? (CPUFreq governor)
These settings, available on both *nix and Windows, can improve the performance and system responsiveness by changing the CPU governor setting from ondemand to performance. This time, let’s compare the descriptions and look for similarities:
Governor = ondemand – Scales CPU frequency dynamically according to the current load. It jumps to the highest frequency and then scales down as the idle time increases.
Governor = conservative = Scales the frequency dynamically according to the current load. Scales the frequency more gradually than ondemand.
Governor = performance – Always run the CPU at the maximum frequency.
See the full list of CPUFreq governor options for further details.
Notice the similarities? The tradeoff is the same one: one setting prioritizes immediate response, the others prioritize idle resource savings.
With CPU governor, the performance setting is a safe performance boost because it’s almost entirely dependent on your server CPU’s limit. The only other factors would be heat, battery life (laptop), and other side effects of permanently clocking your CPU frequency to 100%.
Once set to performance, the cores hold their top frequency instead of scaling down at idle. For example, read about the ‘force_turbo’ setting on Raspberry Pi, which forces your RPi board to use the performance governor where performance improvement is more noticeable due to the low CPU clock speeds.
Using ‘pm static’ to achieve your server’s max performance
The PHP-FPM pm static setting depends heavily on how much free memory your server has. If you suffer from low server memory, then pm ondemand or dynamic may be better options. On the other hand, if you have the memory available, you can avoid much of the PHP process manager (PM) overhead by setting pm static to the max capacity of your server.
In other words, when you do the math, pm.static should be set to the max amount of PHP-FPM processes that can run without creating memory availability or cache pressure issues. Also, not so high as to overwhelm CPU(s) and have a pile of pending PHP-FPM operations.
In the screenshot above, this server has pm = static and pm.max_children = 100, which uses a max of around 10GB of the 32GB installed.
Take note of the highlighted columns, which are self-explanatory. During that screenshot, there were about 200 ‘active users’ (past 60 seconds) in Google Analytics.
At that level, about 70% of PHP-FPM children are still idle. This means PHP-FPM is always set to the max capacity of your server’s resources regardless of the current traffic.
The idle processes stay online waiting for traffic spikes and respond immediately, rather than having to wait on the pm to spawn children and then kill them off after x pm.process_idle_timeout expires.
I have pm.max_requests set extremely high because this is a production server with no PHP memory leaks. You can use pm.max_requests = 0 with static if you have 110% confidence in your current and future PHP scripts. However, it’s recommended to restart scripts over time.
Set the # of requests to a high number since the point is to avoid pm overhead. So, for example, at least pm.max_requests = 1000 …depending on your # of pm.max_children and # of requests per second.
The screenshot uses Linux top filtered by ‘u’ (user) option and the name of the PHP-FPM user. The number of processes displayed are only the ‘top’ 50 or so (didn’t count), but top displays the top stats which fit in your terminal window. In this case, sorted by %CPU. To view all 100 PHP-FPM processes, you can use something like:
top -bn1 | grep php-fpm
When to use pm ‘ondemand’ and ‘dynamic’
Using pm dynamic, you may have noticed errors similar to:
WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children
You may try to increase/adjust settings and still see the same error. In that case, the pm.min was too low and because web traffic fluctuates greatly with dips and spikes, using pm dynamic can be challenging to tune correctly. The common advice is to use pm ondemand.
On a consistently busy server, that backfires: ondemand drops idle workers to 0 when traffic dips, then has to spawn them again the moment it returns, so you trade memory savings for spawn latency exactly when you don’t want it. You could set the idle timeout extremely high to avoid this, but at that point you should just run pm.static + a high pm.max_requests.
However, PM dynamic and especially ondemand can save you when you have multiple PHP-FPM pools, for example, hosting multiple cPanel accounts or websites under different pools. I have a server, for example, with 100+ cPanel accounts and about 200+ domains and it would be impossible for pm.static or dynamic to perform well. In that environment ondemand often performs best, since more than two-thirds of the websites receive little to no traffic and with ondemand, it means all children will be shut down, saving tons of server memory!
Thankfully, cPanel’s devs figured this out and now defaults to ondemand. Previously with dynamic as default, it made PHP-FPM not an option on busy shared servers. Many would use suPHP because of pm dynamic eating up memory even on idle cPanel PHP-FPM pools/accounts. Chances are, if you receive good traffic, you won’t be hosted on a server with lots of PHP-FPM pools (shared hosting).
Conclusion
When it comes to PHP-FPM, once you start to serve serious traffic, ondemand and dynamic can add process-management overhead compared to a properly tuned static configuration, particularly on consistently busy servers. Know your system and set your PHP-FPM processes to match your server’s max capacity.
Don’t guess at pm.max_children, measure it. First find the average resident size of a PHP-FPM worker under real load:
ps --no-headers -o rss -C php-fpm | awk '{ sum += $1; n++ } END { print sum/n/1024 " MB" }'
Then divide the memory you’re willing to give PHP-FPM by that number. If a worker averages 60 MB and you allocate 6 GB to PHP-FPM, that’s roughly pm.max_children = 100 (6144 / 60). Leave headroom for the OS, your web server, and the database, so never hand PHP-FPM all of physical RAM. From there, test under load and adjust on real memory use, CPU utilization, and response times. With pm static, because the workers stay resident, traffic spikes translate into far smaller spikes in load and CPU, and your averages stay smoother.
The average size of your PHP-FPM process will vary per web server requiring manual tuning. Thus, the more automated overhead process managers, dynamic and ondemand, are more popular recommendations.
Update: Added ab benchmark comparison graph. Having PHP-FPM processes sit in memory helps performance at the price of increased memory usage to have them sit in wait. Find your setup sweet spot.
Originally published: Oct 10th, 2017 | Last updated: June 6th, 2026
