总体能力概览
在 Linux 上，PHP-FPM 通过多进程/进程池模型与灵活配置，通常能够稳定支撑数千级并发请求。实际可达并发受多因素共同决定：进程管理模式与池大小、单个 PHP 进程的内存与执行时长、后端（如数据库/缓存/外部 API）能力、以及反向代理与网络栈配置等。合理调优后，既能保证吞吐，又能维持可接受的响应时延与稳定性。
影响并发的关键因素
- 进程管理策略：常见有 static / dynamic / ondemand。static 预创建固定进程，适合稳定高负载；dynamic 按负载伸缩，更省内存；ondemand 按需启停，适合极低流量或资源紧张场景。
- 可用内存与进程数：进程上限通常受内存约束，经验上以“可用内存 ÷ 单进程平均内存”估算 pm.max_children，并预留充足内存给系统与其他服务。
- 请求生命周期与队列：连接排队与超时策略（如 listen.backlog、请求超时）会直接影响高并发下的排队时延与失败率。
- 字节码与代码效率：启用 OPcache 可显著减少脚本解析与加载开销；慢日志有助于定位长耗时脚本与瓶颈。
- 上游与系统资源：数据库/缓存性能、网络带宽与内核参数（如 somaxconn、文件描述符限制）都会成为并发天花板。
并发估算方法与示例
- 核心思路：并发能力 ≈ 同时在处理的 PHP-FPM 工作进程数，而工作进程数受 pm.max_children 与当前负载/模式约束。
- 快速估算：若单进程平均内存为 M（MB），服务器可用内存为 Mem（MB），则理论上限近似为 N_max ≈ Mem ÷ M；实际应再乘以安全系数并预留系统与其他服务内存。
- 示例：可用内存 8GB、单进程 80MB，则 N_max ≈ 8000 ÷ 80 ≈ 100。若平均 RT=100ms，理论上每秒可处理约 100 ÷ 0.1 = 1000 RPS；考虑排队、数据库等瓶颈，实际 RPS 会低于此值。
- 队列作用：当所有进程忙时，新请求进入内核/应用队列（由 listen.backlog 等控制），队列过长会显著增加尾时延，需结合业务容忍度设置。
提升并发的实用配置建议
- 进程池与生命周期
- 稳定高负载优先 pm=static，按内存精确设定 pm.max_children；波动负载用 pm=dynamic，并合理设置 pm.start_servers / pm.min_spare_servers / pm.max_spare_servers。
- 启用 pm.max_requests（如 500–1000）定期重启进程，缓解内存泄漏累积。
- 连接与网络
- 优先使用 Unix Domain Socket（如 listen = /run/php/phpX.Y-fpm.sock）降低连接开销；必要时调大 listen.backlog（如 511 或更高）。
- 提升系统网络栈：如 net.core.somaxconn、net.ipv4.tcp_max_syn_backlog、net.ipv4.ip_local_port_range，并开启 tcp_tw_reuse、合理设置 tcp_fin_timeout。
- 文件描述符与监控
- 提升进程文件描述符限制（如 ulimit -n 65535，并在 /etc/security/limits.conf 配置）。
- 启用 slowlog 与 php-fpm status 页面，持续观测慢请求与进程/队列状态，结合压测迭代调优。
- 应用层加速
- 启用并合理调优 OPcache；减少阻塞 I/O、优化数据库查询与索引、引入 Redis/Memcached 等缓存，降低后端瓶颈对并发的影响。
