Glossary

PHP-FPM

PHP-FPM keeps PHP processes ready for dynamic requests passed from nginx through FastCGI.

Short definition

A PHP worker manager between the web server and application code.

PHP-FPM is the primary FastCGI implementation for PHP. The web server passes information about the script, URI, method, headers, and request body. An available worker initialises PHP, calls the application, and returns the output through FastCGI. When finished, it handles another request, or the manager replaces it after a defined number of requests.

PHP-FPM is neither a web server nor a queue for long-running work. It does not handle TLS, public ports, CSS files, or load balancing of HTTP requests. Its responsibilities are the PHP process model, pool configuration, secure runtime isolation, and diagnosis of slow scripts. It is therefore usually combined with nginx or runs as an internal service on a Docker network.

What it is used for

Running PHP websites, APIs, and administration interfaces within controlled limits

FPM is designed for PHP applications that receive HTTP requests from a separate web server.

Symfony, Laravel, or custom PHP applications served through nginx and FastCGI
multiple pools with different users, php.ini settings, limits, or sockets for separate applications
limiting concurrent PHP requests according to the server’s available memory and performance
diagnosing slow requests through the slowlog, status page, and standard logs
a reproducible PHP runtime in a container where the web server communicates with the application over an internal network

Practical example

A Symfony API behind nginx with a separate FPM pool

nginx accepts HTTPS and sends only the Symfony application’s front controller to an internal FPM socket. The pool has a limited number of dynamic workers, a slowlog, and periodic recycling after a defined number of requests. Neither the database nor the FPM socket is accessible from the public network. Instead of a long request, the order export endpoint creates a task for a worker.

The values are examples, not universal recommendations. max_children is determined from process memory, database concurrency, and the target response time. The status path should be available only on the internal network.

; www.conf
[www]
listen = /run/php/php-fpm.sock
pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log

How it works

From an HTTP request to a PHP worker and back

Each part of the path has its own limit and log, making it possible to identify the source of a problem.

nginx accepts HTTP nginx terminates TLS, selects the server and location, and can return static files without PHP. Only a dynamic path is passed through fastcgi_pass.
FastCGI parameters The web server passes the method, URI, query string, headers, and script path. An incorrectly configured SCRIPT_FILENAME or overly broad PHP location can be both a functional and security problem.
The pool selects a worker A pool listens on a Unix socket or TCP port. An available child process handles the request; if all are busy, the request waits or reaches a limit depending on the surrounding configuration.
The application performs the work PHP loads the Composer autoloader, framework, and application service. A slow SQL query, remote API, or large import occupies the worker for the entire duration.
Response and process recycling FPM returns the response to nginx and the worker remains ready for another request. pm.max_requests can replace a worker periodically to limit the impact of gradually increasing memory consumption.

Main components

The pool, process mode, and limits must match the actual workload.

Configuration is based on memory, request duration, and the number of concurrent requests.

Pool

A pool is a group of workers with its own listen socket, user, environment, and part of the configuration. It can isolate applications or a more sensitive administration interface, but too many pools increase overhead and complexity.

static, dynamic, and ondemand

static keeps a fixed number of workers. dynamic manages a minimum and maximum count according to load. ondemand creates child processes only when requested and terminates them after inactivity; it saves memory but can add startup latency.

pm.max_children

The maximum number of concurrent PHP requests protects the server from uncontrolled process creation. Its value should be based on the real memory usage of one worker and memory reserved for the database and system, not on CPU count as a simple rule.

Socket or TCP

A Unix socket is common on a shared host; TCP is used for separate containers or servers. In either case, the endpoint must remain private and access must be restricted to the web server.

Status, slowlog, and restart

FPM can expose pool status, log unusually long-running scripts, and gracefully restart workers. This information aids diagnosis; it does not replace application metrics, tracing, or fixing slow code.

Benefits and limitations

Ready workers reduce startup overhead, but each consumes memory.

Benefits

a separate PHP process model isolated from HTTP and static files
pools make it possible to set limits and permissions for different applications
child process management, graceful restarts, the slowlog, and status simplify operational diagnosis
integration with nginx handles many ordinary web requests without creating a new PHP process

Risks and mistakes

an excessive pm.max_children can exhaust memory and cause an OOM instead of improving performance
a slow external call or export occupies a worker and reduces the capacity of the entire website
a publicly exposed FPM TCP port permits unintended access to the runtime
an incorrect FastCGI parameter can run the wrong script or break routing
increasing the worker count does not fix a missing database index, lock, or slow integration

Scope of use

Protect the web pool from long-running and batch work.

PHP-FPM is an appropriate choice for HTTP requests with a clear timeout and bounded memory. Capacity is based on actual worker size and headroom for the system, database, and cache. A short endpoint may need a different policy from an administrative export.

Long imports, catalogue recalculations, file generation, and retries of external APIs should not occupy a web FPM worker. A queue or CLI worker gives the task its own limit, retry policy, and monitoring. fastcgi_finish_request can end the client response sooner, but it does not turn long-running work into an independent worker.

What to consider

Set limits from measurements, not a universal number from a guide.

Operations should monitor waiting requests, script duration, memory, and errors from nginx, FPM, and the application.

calculate pm.max_children from actual worker memory and leave headroom for the entire host or container
separate the public HTTP server from the private FPM socket or TCP port
configure FastCGI parameters so the application receives the correct path, scheme, and expected headers
use the slowlog and a status endpoint protected from public access to find blocking requests
align nginx, FPM, and application timeouts with the endpoint type instead of increasing every limit without cause
perform a graceful reload after deployment and verify the health check, errors, and memory consumption of new workers

Common questions

How PHP-FPM affects a website’s operation

Is PHP-FPM a web server?

No. It processes PHP through FastCGI. HTTP, TLS, static files, and the public network boundary are usually handled by nginx or another web server in front of it.

Do more workers always improve performance?

No. More workers increase concurrency but consume memory and can increase pressure on the database or external APIs. Beyond capacity, latency rises or processes run out of memory.

Should a long import run through PHP-FPM?

Usually not. Long-running work blocks a web worker and reduces the availability of ordinary requests. A queue or separate CLI worker with its own timeout, retry policy, and monitoring is more suitable.

Is a Unix socket or TCP port better?

It depends on the topology. A socket is common when nginx and FPM share a host; TCP is practical for separate containers. In either case, the endpoint must not be publicly accessible.

How I think about backend runtime

A web request, worker, and operational limit should each have a clearly separate role.

In PHP applications, I connect architecture, integration work, and operations so that long-running tasks do not jeopardise ordinary APIs and administration interfaces.

How I approach application architecture Discuss your project without obligation