Use dynamic process manager for most cases, static for steady high traffic, and avoid ondemand for high throughput; 2. Set pm.max_children based on available RAM divided by average PHP process memory, leaving headroom to prevent swapping; 3. Configure pm.max_requests to recycle workers and prevent memory leaks, set request_terminate_timeout to kill long-running requests, enable slowlog to track bottlenecks; 4. Use Unix sockets for lower I/O overhead, adjust listen.backlog to match web server settings, increase rlimit_files if needed; 5. Continuously monitor FPM status, upstream response times, and system metrics using tools like htop or Grafana; additionally, enable Opcache with appropriate settings to reduce script parsing overhead and significantly boost performance, as even well-tuned PHP-FPM will underperform without it.

Optimizing PHP-FPM for maximum throughput isn’t about cranking every setting to the max — it’s about aligning configuration with your application’s behavior, server resources, and traffic patterns. Poorly tuned PHP-FPM can lead to slow response times, high memory usage, or even 502 errors under load. Here’s how to get the most out of it.

1. Choose the Right Process Manager (pm)

PHP-FPM supports three process managers: static, dynamic, and ondemand. Your choice directly affects performance and resource use.

• dynamic (Recommended for most cases)
  Balances performance and memory. Keeps a pool of child processes that can grow or shrink based on demand.

  

  pm = dynamic
  pm.max_children = 50
  pm.start_servers = 10
  pm.min_spare_servers = 5
  pm.max_spare_servers = 15

• static
  All child processes are spawned at startup. Best for high, consistent traffic when you can afford the memory.

  pm = static
  pm.max_children = 30

• ondemand
  Spawns children only when requests arrive. Saves memory but increases latency during traffic spikes — not ideal for high-throughput scenarios.

  

? Rule of thumb: Use dynamic unless you have predictable, steady traffic and want to minimize process management overhead.

2. Set pm.max_children Based on Available Memory

This is the most critical setting. Too high = memory exhaustion. Too low = request queuing.

Estimate max_children:

max_children = Total RAM dedicated to PHP-FPM / Average memory per PHP process

For example:

• You allocate 2GB RAM to PHP-FPM
• Average PHP process uses ~64MB
• 2048 MB / 64 MB = 32

So set pm.max_children = 32 (leave some headroom for system overhead).

You can check memory per process using:

ps --no-headers -o "rss,cmd" -C php-fpm | awk '{sum =$1} END {print int(sum/NR/1024)" MB"}'

?? Avoid overcommitting memory — swapping kills performance.

3. Tune Request Handling and Timeout Settings

Long-running or stuck requests can exhaust the worker pool.

pm.max_requests = 500        ; Restart workers after 500 requests (helps prevent memory leaks)
pm.process_idle_timeout = 10s ; For 'ondemand' only
request_terminate_timeout = 30s ; Kill requests taking longer than 30s
request_slowlog_timeout = 5s  ; Log slow requests (pair with slowlog)
catch_workers_output = yes    ; Capture stdout/stderr

• pm.max_requests helps mitigate memory leaks in long-running scripts (e.g., legacy code).
• request_terminate_timeout prevents hanging requests from blocking workers.
• Enable slowlog to identify bottlenecks:

  slowlog = /var/log/php-fpm-slow.log

4. Optimize I/O and Concurrency

PHP-FPM works best when it doesn’t become the bottleneck. Pair it with a fast web server (like Nginx) and optimize request flow.

• Use socket connections instead of TCP (if on same host):

  listen = /run/php/php8.1-fpm.sock
  listen.owner = www-data
  listen.group = www-data
  listen.mode = 0660

  Unix sockets have lower overhead than 127.0.0.1:9000.

• Adjust listen.backlog if you see connection rejections:

  listen.backlog = 511

  Set this close to the web server’s backlog (e.g., Nginx listen ... backlog=511).

• Increase rlimit_files if hitting file descriptor limits:

  rlimit_files = 65535

5. Monitor and Iterate

Tuning is not one-time. Monitor key metrics:

• FPM status page (enable in pool config):

  pm.status_path = /status

  Access via web server to see active/idle processes, queue length, etc.

• Nginx upstream response times — long waits may indicate FPM saturation.

• System metrics: CPU, memory, swap, and load average.

Use tools like htop, sysdig, or Prometheus Grafana for deeper insight.

Bonus: Use Opcache

PHP-FPM handles process management, but Opcache dramatically reduces script parsing overhead.

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0  ; Disable in production (re-enable for deployments)
opcache.fast_shutdown=1

Without Opcache, even perfectly tuned FPM will underperform.

Basically, optimizing PHP-FPM comes down to: matching max_children to memory, choosing the right process manager, preventing stuck requests, and reducing I/O overhead. Combine that with Opcache and monitoring, and you’ll squeeze the most throughput out of your PHP stack.

The above is the detailed content of Optimizing PHP-FPM Configuration for Maximum Throughput. For more information, please follow other related articles on the PHP Chinese website!