PHP worker capacity worksheet

Estimate average PHP work in progress from a measured dynamic-request rate and mean PHP service time, then compare that estimate with a worker limit you have verified. This is a steady-state planning calculation, not a load test or provider-fit verdict.

Enter observations from the same workload and calculate.

How to use the worksheet

1. Choose a representative busy window and count dynamic PHP requests that reached the PHP application during it. Exclude static files and note whether cache layers bypassed PHP.
2. Use application tracing or another measurement that estimates mean PHP service time across those requests. Use seconds after converting milliseconds if you calculate by hand. Do not substitute full browser page-load time, which can include network, queueing, database, and browser work.
3. Enter the simultaneous worker limit from the exact plan or account you are evaluating. Leave the planning ceiling as your own chosen margin; it is an input, not a recommended universal percentage.

Estimated average concurrent PHP work = (requests in window ÷ window seconds) × (mean PHP service milliseconds ÷ 1,000). This uses Little's Law in a steady-state approximation: arrival rate multiplied by average time in the system estimates average work in progress. The worksheet uses PHP service time as that time and does not include time queued before a worker starts.

The planning comparison multiplies your worker limit by your chosen utilization ceiling, then translates that concurrent-work budget into a request-rate scenario using the entered mean service time. These are averages and scenarios: short bursts, uneven request durations, queueing, CPU or memory limits, database waits, background jobs, caching, and other pools can change observed behavior. A result below the entered worker limit does not prove a plan will fit or remain responsive.

Where to measure

PHP-FPM's status page can report current active and idle processes, the maximum active processes seen, listen-queue observations, and whether the configured child-process maximum was reached. It also exposes per-process request-duration information in full output. These are useful operational signals, but a single per-process duration is not a mean across your chosen observation window. Derive comparable request counts and average PHP service time from measurements covering the same workload window.

Only enable or expose an FPM status endpoint according to the server administrator's security guidance: PHP documents that it reveals request URLs and resource information and should be restricted to internal requests or known client addresses. Shared-hosting customers may not have access to FPM metrics; use provider-supported account data or ask support what the published worker limit means.

Sources

• PHP Manual: FPM configuration — documents process-manager modes and the pm.max_children setting that limits simultaneous child processes; checked November 3, 2026.
• PHP Manual: FPM status page — defines active/idle processes, listen queues, maximum active processes, child-limit reach, and per-process request-duration fields; includes a security caution; checked November 3, 2026.
• John D. C. Little, “A Proof for the Queuing Formula: L = λW,” Operations Research 9(3), 1961 — original proof of the average arrival-rate and time-in-system relationship used for the estimate.

For broader user-entered capacity assumptions, see the WordPress resource needs estimator. For request timing and user experience measures, see the Core Web Vitals guide; those metrics do not isolate PHP worker capacity.