PHP-FPM (FastCGI Process Manager) is the PHP execution model that most modern web applications use, and its configuration significantly affects both the performance and the resource usage of PHP-based websites. Understanding how it works helps developers and system administrators make better decisions about server sizing, identify the cause of performance problems, and configure it appropriately for specific workloads.
The basic model: PHP-FPM maintains a pool of PHP worker processes that are ready to handle requests. When a web server receives a request that requires PHP, it passes the request to PHP-FPM, which assigns it to an available worker. If no worker is available and the pool is at its configured maximum, the request waits in a queue until a worker becomes available. This is the mechanism through which PHP-FPM creates the specific failure mode of slow responses under load — not from server resource exhaustion but from request queuing behind a pool that's too small.
The critical configuration parameters:
pm.max_children: the maximum number of PHP worker processes. This is the fundamental capacity limit — no more than this many PHP requests can execute simultaneously. Setting this too low causes queuing under load; setting it too high with insufficient RAM causes memory exhaustion.
pm.start_servers, min_spare_servers, max_spare_servers: how many workers to maintain when idle. For steady traffic, more pre-forked workers reduces latency for incoming requests; for variable or bursty traffic, too many idle workers wastes RAM.
pm.max_requests: how many requests each worker handles before being recycled. Setting this prevents PHP memory leaks from accumulating over many requests, which is a specific cause of memory growth that looks like a leak but is actually accumulated garbage collection overhead.
The PHP web server configuration that most users experience is managed by their hosting provider; understanding what they're managing helps diagnose symptoms. A WordPress site that gets slow specifically under concurrent load, rather than slow always, is often hitting PHP-FPM worker exhaustion — the pool is too small for the traffic. The specific error — 504 Gateway Timeout — occurs when a request waits longer than the configured timeout for an available worker.
Memory limits interact with PHP-FPM sizing in a specific way: if you have 2GB of RAM allocated for PHP-FPM, and each PHP process uses 50MB on average, you can run a maximum of about 40 workers before running out of memory. Setting pm.max_children higher than the memory allows causes OOM errors that kill workers. Understanding this relationship is what connects server infrastructure sizing to application performance planning.
The monitoring signal that PHP-FPM is the bottleneck: 504 errors under load that don't appear under light load, combined with the PHP-FPM pool log showing requests queuing behind a full worker pool. The fix is either upgrading to more resources (more RAM to allow more workers) or optimising PHP application performance (faster PHP requests release workers sooner, increasing effective capacity).
