Boost PHP‑FPM Performance: Why pm‑static Beats Dynamic & ondemand

Introduction

All scripting languages for web applications rely on a server process that manages script I/O. Python uses WSGI, while PHP uses PHP‑FPM, which provides process management, memory control, and application monitoring. This article shows how to optimise PHP‑FPM for high throughput, low latency, and stable CPU and memory usage.

PHP‑FPM Process Manager (PM) Modes

By default many users set pm = dynamic and forget about it. When memory is constrained, the common advice is to switch to ondemand. However, two options are especially useful for high‑traffic sites: static and a carefully tuned dynamic.

pm = dynamic controls the number of child processes with the following directives:

pm.max_children

pm.start_servers

pm.min_spare_servers

pm.max_spare_servers

pm = ondemand creates processes only when a request arrives; pm.start_servers runs at service start.

pm = static fixes the number of child processes to the value of pm.max_children.

For detailed configuration see the official PHP manual.

CPUFreq and PHP‑FPM

CPU frequency scaling can be controlled with the Linux CPUFreq governor. The ondemand governor raises the CPU frequency based on current load, while conservative adjusts more gradually, and performance forces the highest frequency at all times. By pairing a suitable governor with pm = static, you can push server performance beyond typical limits.

Using pm = static for Maximum Performance

If the server has ample free memory, setting pm = static to the maximum number of children eliminates most PM overhead. For example, on a server with 32 GB RAM, pm.max_children = 100 uses about 10 GB, keeping 70 % of processes idle but ready for spikes.

Set pm.max_requests high (or 0) to avoid premature process recycling, and adjust pm.max_requests based on pm.max_children and request rate, e.g., 1000 requests per child.

Use the Linux top command to monitor PHP‑FPM processes:

top -bn1 | grep php-fpm

When to Use ondemand or dynamic

With pm = dynamic you may see warnings such as:

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

If pm.min_spare_servers is too low and traffic spikes are large, dynamic can struggle, and ondemand may close idle processes, causing latency on sudden spikes. In such cases, pm = static with a high pm.max_requests is preferable.

For servers hosting many cPanel accounts or virtual hosts, pm = static is often infeasible; ondemand saves memory by shutting down idle processes, which is why cPanel defaults to it.

Conclusion

When traffic grows, the overhead of ondemand and dynamic managers can limit throughput. Understanding your system and configuring PHP‑FPM to match the server’s capacity—starting with pm = static where memory allows—yields smoother CPU usage and higher performance. Each server’s optimal settings differ, but static mode generally provides the best baseline for high‑performance PHP‑FPM deployments.