A site can have enough disk space and still struggle to answer a request. One reason is that all of its PHP workers are occupied. Understanding those workers helps you make sense of queues, memory use and slow pages.
A worker handles application work
PHP-FPM processes PHP requests in workers. A busy worker remains occupied until the request completes, even while waiting on a database or external service. Static files served directly by the web server do not need a PHP worker.
A worker limit is a concurrency boundary, not a visitor count. Ten people reading cached pages can use less PHP capacity than one slow export. Identify which requests reach PHP and how long they occupy workers.
Pool size and request memory are different
The maximum child count caps concurrent workers. PHP’s memory limit constrains a script’s allocation, not every byte in the process or server. Setting both values high can create a capacity expectation the host cannot meet.
For illustration, twenty workers using roughly 100 MiB each may need around 2 GiB before accounting for shared services and variation. Measure your application; this calculation is not a recommended deployment setting.
Choose a mode for the workload
Static mode maintains a fixed pool. Dynamic mode changes worker counts within configured bounds. On-demand mode starts workers for incoming requests and retires idle ones. Idle footprint, process startup and bursts all matter.
Use the panel’s supported configuration process. Direct edits can be replaced when the panel rebuilds managed files. Review changes, validate configuration and retain the previous values for rollback.
| Control | Meaning |
|---|---|
| Maximum children | Concurrent PHP worker ceiling |
| Request timeout | How long a request may hold a worker |
| Idle behavior | Processes retained between requests |
Read queue evidence before adding capacity
Restricted FPM status can show active and idle workers, listen queues and reached-limit counters. Interpret those with timestamps and latency. A cumulative limit counter does not prove that the pool is currently saturated. Do not expose status publicly.
If workers wait on the database, a larger pool can move the bottleneck and make the dependency busier. Investigate slow requests first. Pool tuning is one part of application and server capacity planning, not a guaranteed speed improvement.
Estimate work in flight
A worker remains occupied while processing a request, including time spent waiting for a database or remote API. A planning model is concurrency ≈ requests per second × average duration. Eight requests per second averaging half a second imply four requests in flight on average. This is an illustration, not a capacity benchmark or safe pool recommendation.
Bursts and slow requests matter more than that average suggests. Cached public pages may avoid PHP while a handful of slow checkouts hold workers. Measure the path you care about and include background PHP work in the budget.
Interpret process memory carefully
This command lists processes by resident memory. RSS helps identify large processes, but shared pages can appear in multiple processes; adding RSS may overstate private memory. Compare repeated samples during representative work rather than using the smallest idle process as your budget.
PHP memory_limit is a per-script ceiling, not a reservation per worker. Raising it and the pool ceiling together can sharply change worst-case demand. Check total pressure and other services before increasing concurrency.
ps -eo pid,user,rss,comm --sort=-rss | head -n 20
free -hMatch the action to the bottleneck
Idle workers and slow requests suggest a different problem from a saturated pool. If workers wait on a remote API, inspect timeouts and application behavior. If CPU is saturated, more workers may increase contention.
In EzePanel, review effective package policy and PHP assignment first. Keep the previous setting and verify a real transaction after an approved change. More concurrency should support useful work, not multiply a slow dependency.
Where to go next
Sources & further reading
Official documentation for the topics in this guide. Check current vendor requirements before a purchase or server change.
