{"id":1144,"date":"2026-09-16T02:02:04","date_gmt":"2026-09-16T02:02:04","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1144"},"modified":"2026-09-16T22:03:39","modified_gmt":"2026-09-16T22:03:39","slug":"tuning-php-fpm-process-pools-by-workload","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/tuning-php-fpm-process-pools-by-workload\/","title":{"rendered":"Tuning PHP-FPM Process Pools by Workload Type, Not by Copy-Paste"},"content":{"rendered":"\n\n

Most PHP-FPM advice on the internet is a single number \u2014 “set pm.max_children<\/code> to 25″ \u2014 copied between articles of wildly different workloads. That number is wrong for a WooCommerce checkout and wrong for a mostly-cached brochure site, and in both cases the failure mode is silent: some requests queue at the pool boundary and time out while CPU sits at 40%. This guide sizes a pool from the workload up. If you are still deciding how much machine to buy, the trade-off between shared hosting and a VPS<\/a> is exactly the sizing decision this article assumes you have already made.<\/p>\n\n\n\n

Start with the memory ceiling, not with a child count<\/h2>\n\n\n\n

Each PHP-FPM child holds a resident footprint. That footprint is the true constraint on a VPS, because when children oversubscribe RAM the kernel either swaps (killing latency) or the OOM killer removes a child mid-request (killing correctness). Measure it properly on a live system rather than guessing from top<\/code>:<\/p>\n\n\n\n

# Average RSS of the 5 largest PHP-FPM workers, in MB\nps --no-headers -o rss,cmd -C php-fpm8.3 \\\n  | sort -rn | head -5 \\\n  | awk '{ sum += $1; n++ } END { printf \"avg %.1f MB\\n\", sum\/n\/1024 }'<\/code><\/pre>\n\n\n\n
Then subtract what everything else needs from total RAM:<\/p>\n\n\n\n
# Budget example on a 4 GB VPS\n#   OS + systemd + sshd .......... 250 MB\n#   nginx ......................... 120 MB\n#   MySQL\/InnoDB buffer pool ..... 1200 MB\n#   Redis ......................... 200 MB\n#   --------------------------------------------\n#   Available for PHP-FPM ........ 2230 MB\n#   Average worker RSS ........... 45 MB\n#   Safe max_children ............ 2230 \/ 45  ~= 49\n#   Apply a 20% safety margin .... 39<\/code><\/pre>\n\n\n\n
Thirty-nine is your hard ceiling. The process manager you choose determines whether you actually approach it.<\/p>\n\n\n\n
Choose the process manager from the traffic shape<\/h2>\n\n\n\n
Manager<\/th>Behaviour<\/th>Best for<\/th>Avoid when<\/th><\/tr><\/thead>
static<\/code><\/td>Fixed N children, always resident<\/td>Steady high traffic; memory dedicated to PHP<\/td>Traffic varies 5x between day and night<\/td><\/tr>
dynamic<\/code><\/td>Scales between min and max spawns<\/td>Most production LEMP stacks with predictable peaks<\/td>Very spiky traffic causes spawn churn<\/td><\/tr>
ondemand<\/code><\/td>Spawns on demand, reaps when idle<\/td>Low traffic, many sites, small RAM VPS<\/td>High request rate \u2014 spawn overhead dominates<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The critical detail: ondemand<\/code> has a hard request-rate ceiling imposed by fork cost, roughly 100\u2013300 spawns per second before it becomes the bottleneck. On a busy site it will produce exactly the symptom people misattribute to PHP being slow \u2014 first-byte latency that grows with concurrency.<\/p>\n\n\n\n
Cached content site (WordPress + Redis + Nginx FastCGI cache)<\/h3>\n\n\n\n
When 90%+ of requests are served from cache, PHP only handles uncached pages, admin traffic, and cron. You need few children but each should be stable.<\/p>\n\n\n\n
pm = dynamic\npm.max_children = 12\npm.start_servers = 4\npm.min_spare_servers = 3\npm.max_spare_servers = 8\npm.max_requests = 500<\/code><\/pre>\n\n\n\n
Uncached database-driven application (SaaS, custom CMS)<\/h3>\n\n\n\n
Every request touches PHP and the database. Concurrency maps directly to DB connections, so this is where pool sizing and database max_connections<\/code> must be reconciled \u2014 otherwise you trade a PHP queue for a MySQL “too many connections” error.<\/p>\n\n\n\n
pm = dynamic\npm.max_children = 25\npm.start_servers = 8\npm.min_spare_servers = 8\npm.max_spare_servers = 20\npm.max_requests = 300\npm.status_path = \/fpm-status<\/code><\/pre>\n\n\n\n
Check the sum: 25 PHP children \u00d7 1 persistent connection each = 25 connections. MySQL’s default max_connections<\/code> of 151 is fine. If you run multiple pools, add them up.<\/p>\n\n\n\n
Batch and queue workers (Laravel Horizon, cron processors)<\/h3>\n\n\n\n
Workers do not serve HTTP and should not share a pool with web traffic at all. Give them their own pool with static<\/code>, a number matching your CPU core count, and long timeouts that would be unacceptable for web requests.<\/p>\n\n\n\n
[www]\npm = static\npm.max_children = 4\npm.max_requests = 1000\nrequest_terminate_timeout = 900\n\n[workers]\npm = static\npm.max_children = 2\npm.max_requests = 50\nrequest_terminate_timeout = 3600<\/code><\/pre>\n\n\n\n
Two separate pools under one master. Without this split, one long-running import job can hold half your web workers hostage \u2014 a failure pattern that shows up as random 504s during scheduled tasks.<\/p>\n\n\n\n
Recycling: the settings that cause slow leaks and slow first requests<\/h2>\n\n\n\n
pm.max_requests<\/code> restarts a child after N requests. It exists to bound memory leaks and fragmentation, but it has a real cost: every restart discards the opcode cache warm-up for that worker and forces fresh database connections.<\/p>\n\n\n\n