PHP-FPM 并发能力上不去，常见原因通常不是某一个配置写错，而是进程池规模、慢请求、代码耗时和系统资源限制叠在了一起。实际调优时，建议先从 /etc/php-fpm.d/www.conf 这类直接影响吞吐的配置入手，再结合代码与系统指标逐层排查，这样更容易判断瓶颈究竟出在哪一层。
先从进程管理器配置下手
进程池配置是 PHP-FPM 并发能力最直接的调优入口。通常先打开 /etc/php-fpm.d/www.conf，重点看与进程数量和空闲进程相关的参数。
如何选择 pm 模式
pm 用来决定进程管理方式，常见可选项里，更适合大多数业务场景的是 dynamic 或 ondemand。
dynamic：适合请求量相对稳定、需要更快响应的场景。ondemand：适合流量波动较大的场景，空闲时更省资源。- 静态模式通常不建议优先使用，因为进程长期常驻，资源浪费会更明显。
怎样估算 pm.max_children
pm.max_children 决定最多能同时处理多少个 PHP 请求，是影响并发上限的核心参数之一。这个值不能靠猜，通常要结合服务器内存和单个 PHP 进程的平均内存占用来估算。
常见估算方式是：
总内存 / 每个进程平均内存如果这个值设置过小，请求高峰时会排队；设置过大，又可能把机器内存吃满，反过来拖垮整台服务器。
启动数和空闲进程怎么配
除了最大子进程数，还要关注下面几个参数：
pm.start_servers：启动时的进程数，一般可先按 CPU 核心数的 4 倍作为经验值起步。pm.min_spare_servers：最小空闲进程数。pm.max_spare_servers：最大空闲进程数。
这几项主要用于控制空闲进程池规模，减少高峰来临时频繁创建进程、低峰时又频繁销毁进程的开销。
别让慢请求长期占住进程
即使进程池规模设置合理，慢请求如果长时间不释放，同样会把并发能力拖下来。这个阶段重点关注超时参数，位置通常在 www.conf 或 php-fpm.conf。
request_terminate_timeout 的作用
request_terminate_timeout 用来限制脚本最大执行时间。这个值设置过大，挂起或异常请求会持续占用 PHP-FPM 子进程，导致后续请求只能等待。
更稳妥的思路是结合业务实际，把它控制在能覆盖正常请求、又不会纵容异常慢请求的范围内。
为什么 fastcgi_read_timeout 也要一起看
fastcgi_read_timeout 影响 FastCGI 读取超时。如果这个时间过长，前端服务在面对慢请求时会长期等待后端返回，进一步放大阻塞效应。
因此，PHP 执行超时和 FastCGI 读取超时通常需要配合调整，避免一端已经失去处理价值，另一端还在继续等待。
配置只能托底，代码效率才决定上限
如果应用本身执行慢、占内存高，单纯扩大 PHP-FPM 进程池只是在放大资源消耗。真正决定并发表现上限的，仍然是代码路径是否足够高效。
优先开启 OPcache
开启 OPcache 后，PHP 中间代码可以被缓存，能减少重复编译带来的时间开销。这通常是成本最低、收益最直接的一项优化。
减少数据库和外部 API 的重复开销
很多所谓的 PHP-FPM 并发不足，本质上是单次请求里数据库查询太多、外部 API 调用太频繁。能缓存的内容尽量缓存，能合并的查询尽量合并，比单纯调高进程数更有效。
控制数据结构和内存占用
大数组、重量级对象、低效算法都会直接抬高单个进程的内存占用。进程越重，pm.max_children 可设置的空间就越小，并发能力也会被压缩。
所以在评估 PHP-FPM 参数前，最好先确认请求链路里是否存在明显的内存浪费。
系统层限制经常才是真正瓶颈
当 PHP-FPM 配置已经调整过，但高并发下仍然出现连接堆积、响应变慢或报错，就需要继续往操作系统层排查。
先检查文件描述符限制
文件描述符上限不足时，连接数稍高就可能触发 “too many open files”。可以先用下面的命令检查并调整：
ulimit -n这个限制如果太低，再多的 PHP-FPM 子进程也接不住并发连接。
适当提高 TCP 队列参数
高并发场景下，可以关注 TCP 连接队列长度相关参数，例如：
net.core.somaxconnnet.ipv4.tcp_max_syn_backlog
这些参数会影响连接进入系统后的排队能力。数值过小，高峰期就更容易在入口处出现拥堵。
减少交换带来的性能抖动
vm.swappiness 也值得关注。这个参数如果不合适，在内存紧张时系统可能更频繁地进行磁盘交换，导致 PHP 请求整体变慢。
对于依赖响应速度的 Web 服务，减少不必要的 swap 行为通常更有利于稳定吞吐。
单机到顶后，再考虑负载均衡
当单台机器的 CPU、内存和连接能力都接近上限时，继续在本机上挤参数空间的收益就会越来越低。这时更现实的做法，是把请求分散到多个 PHP-FPM 实例上。
通过 Nginx 或 Apache 分发请求
可以使用 Nginx 或 Apache 作为反向代理，把请求均匀转发到多个后端 PHP-FPM 进程池。这样做的核心价值不只是提升峰值并发，也能降低单节点故障对整体服务的影响。
多实例部署别忽略会话和文件同步
横向扩展后，需要额外处理会话共享和文件同步问题。特别是依赖本地 Session 或本地上传文件的项目，如果这些问题没处理好，请求虽然分散了，业务却可能出现登录状态丢失或文件不一致。
监控数据决定你该往哪一层继续调
PHP-FPM 并发调优不是一次性动作，而是持续观察、逐步修正的过程。没有监控数据，就很难判断到底是进程不够、慢请求太多，还是系统资源已经触顶。
先看 CPU、内存和进程池状态
可以先用这些工具做基础观察：
tophtopphp-fpm-status
前两者适合查看 CPU 和内存整体占用，php-fpm-status 则更适合判断进程池是否繁忙、是否存在排队和慢请求积压。
调优要反复验证，不要一次改太多
比较稳妥的方式，是每次只调整一组关键参数，然后结合监控结果观察变化。这样才能明确知道，是 pm.max_children 带来了改善，还是代码缓存、超时控制、系统限制调整发挥了作用。
最后还要保留原始配置备份。不同硬件条件、业务逻辑、访问模型下，最优解都不一样，能快速回滚，才适合在线上环境持续试错。
