WordPress
PHP worker sizing: match concurrency to memory, CPU and request time
PHP worker sizing decides how many PHP requests can execute concurrently and how much memory that concurrency can consume. Too few workers create queues; too many can exhaust RAM or overload the database. The right number comes from request duration, traffic concurrency, per-worker memory, and the rest of the stack.
Measure real concurrent PHP demand
Separate cached/static requests from requests that actually reach PHP. During a busy period, record active/idle workers, queued requests, request duration, CPU usage, and memory. A site serving 100 requests per second from cache may need fewer PHP workers than a lower-traffic uncached WooCommerce site.
Look for pool saturation messages or queue growth before assuming every slow page is a worker problem.
Budget memory per process
Measure representative PHP process RSS across normal and expensive requests, then reserve RAM for the operating system, web server, database, cache, mail/control-panel services, and filesystem cache. Multiplying a maximum worker count by a guessed memory_limit can overstate or understate real pressure.
Watch OOM events and swap activity during bursts.
Reduce slow request occupancy
A slow database query, remote API call, image task, or plugin lock can hold a worker for seconds. Fixing that latency can increase throughput without raising the worker ceiling.
Profile expensive endpoints and move long background work out of synchronous web requests where the application supports it.
Increase gradually and retest
Raise the pool limit in controlled steps only when CPU, RAM, and database capacity have headroom. Repeat the same traffic or load scenario and verify queue time improves without memory pressure or database contention.
- Count uncached PHP concurrency.
- Measure worker memory.
- Fix long-running requests.
- Retest after each pool change.