Performance

PHP-FPM Workers Explained for Shared Hosting

Understand PHP workers, process-manager modes and concurrency limits before changing a hosting account’s pool.

By EzePanel Team3 min read
PHP-FPM Workers Explained for Shared Hosting illustrated article cover with EzePanel branding

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.

ControlMeaning
Maximum childrenConcurrent PHP worker ceiling
Request timeoutHow long a request may hold a worker
Idle behaviorProcesses 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.

Sources and review notes

Checked 17 October 2026. Vendor terms, supported versions and prices can change. Follow the official source before a purchase or server change.

Explore the actual product

See how EzePanel fits your hosting.

Read the workflows, limits and requirements before choosing a plan.

Explore featuresReview pricing