Understanding php-fpm’s Three Process Modes: ondemand, dynamic, static

php-fpm (FastCGI Process Manager) replaces many PHP FastCGI features and is valuable for high‑load websites; this article details its three process modes.

php-fpm supports three modes: ondemand, static, and dynamic, which can be configured simultaneously in a single FPM master.

ondemand

When php-fpm starts, no workers are launched for the pool; workers are created on demand when connections arrive.

Configuration example (php-fpm.conf) shows a pool named test .

Principle diagram:

Key points:

Workers are created when a connection arrives, not when a full request is received.

The number of workers is limited by pm.max_children and the global process.max setting.

A 1‑second timer checks for idle workers; if idle time exceeds pm.process_idle_timeout, the worker is terminated.

Configuration requirements

pm.max_children

> 0 pm.process_idle_timeout > 0 (default 10s if not set)

Pros and Cons

Pros: Workers are created based on traffic demand, avoiding unnecessary resource usage.

Cons: Each request must first establish a connection, causing the master process to handle many short‑lived connections, which can become a CPU bottleneck under very high load.

dynamic

At startup, php-fpm launches a number of workers and dynamically adjusts the count during operation, constrained by pm.max_children and the global process.max .

Principle diagram:

Key behavior (1‑second timer):

Checks idle workers and adjusts count up or down.

When increasing, total workers must stay ≤ pm.max_children and ≤ global process.max.

When decreasing, a worker is closed only if idle > pm.max_spare_servers.

If idle >= pm.max_children, a warning is logged.

Configuration requirements

pm.min_spare_servers

and pm.max_spare_servers range: (0, pm.max_children] pm.max_children > 0 pm.min_spare_servers ≤

pm.max_spare_servers

pm.start_servers

must be within [ pm.min_spare_servers, pm.max_spare_servers]; default is pm.min_spare_servers + ( pm.max_spare_servers ‑ pm.min_spare_servers) / 2

Pros and Cons

Pros: Dynamic scaling avoids resource waste; the master’s 1‑second timer has negligible impact.

Cons: If all workers are busy, a new request may wait up to one second for the next scaling cycle.

static

php-fpm starts a fixed number of workers; no scaling occurs during runtime. The 1‑second timer only gathers status metrics such as idle and active worker counts.

Principle diagram:

Configuration requirements

pm.max_children

> 0 (the only effective parameter)

Pros and Cons

Pros: Simple configuration; worker count is set based on CPU cores and response time, eliminating runtime scaling complexity.

Cons: Requires careful sizing; over‑provisioning wastes resources, under‑provisioning limits throughput.

Overall, php-fpm’s three modes offer trade‑offs between resource efficiency and response latency, allowing administrators to choose the best fit for their traffic patterns and hardware constraints.