What Is PHP-FPM?
PHP-FPM stands for FastCGI Process Manager. It manages pools of PHP worker processes on a server. Each worker runs PHP code and sends its result back to the web server.
If you search “what is PHP-FPM,” the key point is that it runs PHP work. It is not a language feature or code editor. You write PHP files separately, then PHP-FPM can run them when a web server sends requests.
People asking “how do I use PHP?” may mean writing a script or serving a website. PHP-FPM matters for the second task. It links a web server, such as Nginx, to the PHP code behind a page.
Nginx can serve files like images and stylesheets, but it does not run PHP itself. It sends PHP requests to PHP-FPM, which returns the result. The PHP manual's PHP-FPM documentation explains its role and setup.
PHP-FPM can also work with Apache. It is one way to run PHP on a web server, not a tool for writing PHP. A “PHP admin” panel may help manage hosting, but it is separate from PHP-FPM.
How PHP-FPM Handles Requests
A browser asks for a page. Nginx checks the request and sends PHP work to a PHP-FPM pool. A pool is a group of workers that share settings.
An idle worker runs the script, then sends its output to Nginx. Nginx returns that output to the browser. Static files can skip PHP-FPM and go straight to the visitor.
Several workers can serve separate requests at once. This is called concurrency. If all workers are busy, new requests wait until a worker is free.
- Nginx receives a request from a browser.
- Nginx sends PHP work to the right pool.
- A free worker runs the script and returns its output.
- Nginx sends the result back to the browser.
FastCGI is the link that lets a web server send work to another program. PHP-FPM uses FastCGI to receive PHP requests. The web server and PHP workers run as separate processes.
Each pool can run under a set system user and group. Separate pools can use different users and limits. This helps keep apps apart on a shared host.
Why Use PHP-FPM?
PHP-FPM keeps workers ready for new requests. Reusing a worker avoids starting a new process for every visit. This can cut delay on a busy site.
Worker limits help control memory use. Each worker needs memory, and its needs can rise while a script runs. Too many workers can leave too little memory for the database or the operating system.
PHP-FPM lets each pool have its own settings. A busy app can have more workers than a small site. Separate pools can also run under separate system users.
Do people still use PHP? Yes. WordPress and many other sites run on PHP. Whether PHP fits a new project depends on the work, the team, and the hosting plan.
PHP-FPM matters most when a server runs PHP behind Nginx. It helps manage requests, but it cannot fix slow code or a slow database. Check each part of the request path when a page feels slow.
Configure PHP-FPM with Nginx
First, install PHP-FPM and the PHP add-ons your app needs. Package and service names vary by system. Follow the setup steps for your Linux version.
Next, set the pool user, worker mode, and listening address. The pool file holds these values. Nginx must send PHP requests to the same address that PHP-FPM uses.
A Unix socket is a local link between programs on one server. It often suits a setup where Nginx and PHP-FPM share a host. Set its access rights so the Nginx user can connect.
A TCP socket uses an IP address and port. It can link services on separate hosts, but it needs careful access rules. Keep it off the public internet. Allow only trusted hosts or a private network.
Test the Nginx settings before you reload the service. Then reload PHP-FPM and request a PHP page. If it fails, check the logs for both services.
- Install PHP-FPM and the add-ons your app needs.
- Set the pool user, worker mode, and listening address.
- Point Nginx's PHP rule to that address.
- Test the settings, reload both services, and check a PHP page.
PHP-FPM Settings That Matter
The pm setting controls how PHP-FPM manages workers. static keeps a fixed number ready. dynamic changes the count within set limits. ondemand starts workers when requests arrive.
pm.max_children sets the most workers that can serve requests at once. A higher limit may handle more traffic, but it also uses more memory. Set it based on the memory set aside for PHP-FPM.
For example, a pool with 600 MB available might fit about 12 workers at 50 MB each. Treat this as a rough estimate. Worker use can rise during busy requests, so check memory under load.
With dynamic mode, pm.min_spare_servers sets the smallest number of idle workers to keep ready. pm.max_spare_servers sets the largest idle count. These limits help PHP-FPM balance quick replies against memory use.
If the idle count falls below the minimum, PHP-FPM can start more workers. If it rises above the maximum, it can stop extra workers. Set both values with care. A high idle count wastes memory, while a low count may slow a sudden rush.
There is no single best setting for every site. Watch worker use, memory, and request wait times during normal and peak traffic. Change one setting at a time, then compare the results.
Troubleshoot PHP-FPM Problems
A “502 Bad Gateway” error can mean Nginx cannot reach PHP-FPM. Check that both services are running. Then compare the address in the pool file with the address in Nginx.
Socket access rights can also block the link. For a Unix socket, check its owner, group, and permissions. For a TCP socket, check the port and network rules.
If requests wait during busy periods, the pool may have too few workers. Check whether all children are busy and whether memory has room for more. Raising pm.max_children without checking memory can make the server run out of space.
If memory use stays high while traffic is low, review the pool mode and spare worker limits. A process may also use more memory than expected. Check logs and watch the server during real requests before changing limits.
PHP-FPM is one part of the web stack. Slow pages can also come from PHP code, a database, or network delays. Test each part before you tune the worker pool.