What Is PHP-FPM and How Does It Work?
Author: Domeny.ForSale editorial team Published
In brief: PHP-FPM (FastCGI Process Manager) manages processes that execute PHP code on a server. It works with the web server and manages worker processes that can handle successive requests without starting the interpreter again each time. This helps serve websites efficiently, including those built on WordPress, but does not guarantee faster loading on its own—the application code, database and available resources also matter.
How PHP-FPM handles a page request
When a user opens a page that requires PHP execution, the request first reaches a web server such as Nginx or Apache. The server passes the task to PHP-FPM over FastCGI, a communication protocol between the web server and the process running the application. PHP-FPM assigns the request to a worker process, and the result of executing the code returns to the web server and then to the browser.
A worker process is a running PHP process ready to execute a script. After handling a request, it usually remains available for the next one rather than exiting immediately. This avoids the overhead of starting a new interpreter for every request, as happens with traditional CGI.
For example, opening a dynamic page on a WordPress site may require running PHP, reading data from a database and generating HTML. PHP-FPM is responsible for executing the PHP part, not for every stage of delivering the page. The web server usually serves CSS files, images and other static assets without involving it.
How PHP-FPM differs from PHP and a web server
PHP is a language and a runtime that executes code, while PHP-FPM manages that runtime’s processes. It is not a separate language, a content management system or a replacement for Nginx or Apache. These components serve different purposes and can work together.
Nginx delegates the execution of PHP scripts to an external mechanism, often PHP-FPM. Apache can also use PHP-FPM, although some configurations use the mod_php module, which executes PHP within Apache processes. You should therefore not assume that every server running PHP works in the same way.
PHP-FPM does not replace OPcache either. OPcache stores compiled PHP code in memory, reducing the need to parse and compile files again. PHP-FPM manages processes, while OPcache reduces some of the work those processes perform—the two can complement each other.
When PHP-FPM helps and what it cannot fix
PHP-FPM lets you control the number of processes, when they start and when they are recreated. This helps you match application request handling to the server’s resources and the number of concurrent requests. However, enabling it will not necessarily produce a noticeable speed improvement over every other properly configured method of running PHP.
If an online shop is waiting for a slow database query, PHP-FPM alone will not make that query faster. Nor will it eliminate delays from an external API or expensive operations performed by a plugin. Increasing the number of processes may even worsen database overload or exhaust memory.
Full-page caching matters too. If ready-made HTML can be returned without running PHP, that request does not occupy a PHP-FPM process. Shopping carts, administration panels and personalised pages are different: they may require code execution.
Key process settings
PHP-FPM groups processes into pools: separately configured sets of worker processes. Pools can have different limits and run with the permissions of different system users, making it easier to separate applications. However, splitting processes into pools does not by itself provide complete security isolation.
The pm setting determines how processes are managed:
static— maintains a fixed number of processes; this makes their number predictable but uses memory even when traffic is low.dynamic— adjusts the number of processes within defined limits and keeps a reserve of idle processes.ondemand— starts processes when requests arrive and terminates them after a period of inactivity; this reduces memory use during idle periods, at the cost of having to start processes when requests resume.
The pm.max_children parameter sets the maximum number of worker processes in a pool, and therefore the number of PHP requests the pool can execute simultaneously. When all processes are busy, further requests may wait in a queue. Excessive waiting or overload can result in an error.
For example, with a limit of 10 processes, eleven concurrent requests requiring PHP cannot all execute at once. This does not mean the site is limited to 10 users—a user occupies a process only while a particular request is being handled, not throughout their browsing session.
How to check whether the configuration needs changing
On shared hosting, the provider usually manages PHP-FPM settings. Your control panel may only let you select the PHP version and adjust certain limits. Check the hosting documentation or contact support to confirm whether PHP-FPM is available, which settings you can change and what resource limits apply.
On your own server, start with measurements rather than increasing limits. Check whether the pool reaches pm.max_children, how much memory processes use under load, and whether the CPU and database have spare capacity. When properly configured, the PHP-FPM slow request log can help identify code that takes a long time to execute.
A practical next step: choose one slow operation, such as opening the shopping cart, and establish whether the delay comes from waiting for an available process or from the application’s execution itself. Use that finding to decide whether to change PHP-FPM limits or work on the code and database.
See also: What does www mean?
Read also
