优化 Nginx 配合 PHP-FPM 的 keepalive 连接数以提升吞吐量，关键在于启用长连接复用并合理配置进程池。首先，在 Nginx 中配置 fastcgi_keepalive 或 upstream keepalive（若通过 HTTP 代理），减少 TCP 握手开销。其次，调整 PHP-FPM 的 pm.max_children 确保足够进程处理并发，同时设置 listen.backlog 防止队列溢出。推荐使用 Unix Domain Socket 代替 TCP 以降低上下文切换。最后，结合系统内核参数如 tcp_max_tw_buckets 调优，并通过压测验证连接数稳定性与延迟变化，确保配置生效。
Nginx 反向代理中的 Keepalive 连接池性能优化实战
必须显式配置 upstream keepalive,因 Nginx 默认不复用后端连接，导致频繁建连、CPU 开销高、TIME_WAIT 堆积及延迟升高;需合理设置 keepalive、keepalive_requests 和 keepalive_timeout 参数，并配合 proxy_http_version 1.1 等头部配置确保复用生效。在 Nginx 反向代理场景中，启用并合理配置 Keepalive 连接池，能显著降低后端建连开销、提升吞吐量、减少 TIME_WAIT 堆积，但默认配置往往不够用，需结合业务特征调优。为什么必须显式配置 upstream keepalive Nginx 默认对每个请求都新建后端 TCP 连接 (HTTP/1.1 虽支持 keepalive，但 Nginx upstream 不自动复用),频繁短连接会导致：• 后端服务 CPU 消耗集中在 SSL 握手和 TCP 三次握手 • 客户端并发高时，后端出现大量 TIME_WAIT 连接 • 网络延迟敏感型接口 (如 API 网关)P95 延迟明显抬升 只有通过 keepalive 指令显式开启连接池，Nginx 才缓存空闲连接供后续请求复用。关键参数设置与取值逻辑 keepalive N:单个 worker 进程为该 upstream 维护的空闲长连接最大数量 • 建议值 = 后端单实例能稳定承载的并发连接数 × 0.6～0.8 • 例如后端 Tomcat maxConnections=200，则设为 120～160，避免上游连接数超过后端处理能力 keepalive_requests N:单个 keepalive 连接最多承载多少次请求后主动关闭 • 默认 100，建议调大至 1000～10000(取决于后端是否支持 HTTP/1.1 pipelining 及连接稳定性) • 过小会频繁断连重连;过大可能因连接空闲超时被后端主动断开 keepalive_timeout N:空闲连接在 Nginx 连接池中保留多久 (秒) • 必须小于后端服务的 keepalive timeout(如 Nginx 设 60s，后端至少设 75s) • 生产环境推荐 30～60s，兼顾复用率与连接新鲜度 配套 HTTP 头与协议细节不可忽略 仅配置 keepalive 还不够，还需确保请求真正走复用路径：• 在 location 块中显式添加 proxy_http_version 1.1;(HTTP/1.0 不支持 keepalive) • 添加 proxy_set_header Connection '';清除客户端传来的 Connection: close 头，防止 Nginx 误判 • 若后端是 gRPC 或 HTTP/2 服务，需改用 grpc_pass 或升级到支持 h2 的 upstream(keepalive 对 h2 同样生效) • 检查后端响应头是否含 Connection: keep-alive，若返回 close,Nginx 将不复用该连接 验证与压测要点 优化是否生效，不能只看配置，要实测：• 使用 ss -tnp | grep :port | wc -l 观察 Nginx 到后端的 ESTABLISHED 连接数是否稳定在 keepalive 设定值附近 • 用 wrk 或 hey 发起持续压测 (如-w 30s -c 200),对比开启前后端连接数、平均延迟、错误率变
【PHP 部署性能优化终极指南】:Nginx + PHP-FPM 高并发配置秘诀全公开
opcache.memory_consumption=256 opcache.max_accelerated_files=20000 opcache.validate_timestamps=0// 生产环境设为 0，禁用文件检查 上述配置通过预编译并缓存脚本的 OPcode，避免重复解析，提升执行效率。不当的数据库操作是常见的性能陷阱。频繁建立连接、未使用索引或 N+1 查询问题会显著拖慢响应速度。使用 PDO 或 MySQLi 的持久连接 (PDO::ATTR_PERSISTENT) 通过 EXPLAIN 分析慢查询执行计划 引入 Redis 等缓存层减轻数据库压力 传统 PHP-FPM 配合 Nginx 的模型在高并发下易因进程阻塞导致资源浪费。可通过调整 FPM 子进程配置提升吞吐量：
| 配置项 | 推荐值 (4 核 8G 服务器) | 说明 |
|---|---|---|
| pm | dynamic | 动态调整进程数 |
| pm.max_children | 50 | 最大子进程数 |
| pm.start_servers | 10 | 启动时开启的进程数 |
php-fpm 多实例，php-fpm 多实例提升系统吞吐量和服务器资源利用率
排除了依赖的资源 mc、redis 原因后，那剩下的就是 nginx 和 php-fpm 本身，继续分析，nginx 用的是 tengine2.1.2，之前做 cache 时并发连接数测到 30 万、QPS1.5 万没出过问题，那最有可能就是 php-fpm 本身遇到了瓶颈了。对于 php-fpm，之前将进程数从 128 调到了 256，继续加大并不是办法，可能根本就不是进程数的问题了，后来多次思索，果断效仿 tomcat 多实例的方法对 php-fpm 做多实例，想着最大限度的利用服务器闲散的 cpu、内存、io、网络，提高单台服务器的吞吐量。调整思路及步骤：1、新建 php-fpm 的配置文件 php-fpm2.conf 第 1 个实例用的 9000 端口，第 2 个实例用 9001 端口，修改后的配置文件 (php-fpm2.conf) 如下:[global] pid = run/php-fpm9001.pid error_log = /data1/var/logs/php-fpm/error9001.log log_level = warning emergency_restart_threshold = 10 emergency_restart_interval = 1m process_control_timeout = 5s daemonize = yes [www] listen = 127.0.0.1:9001 listen.backlog = -1 listen.allowed_clients = 127.0.0.1 user = www group = www pm = static pm.max_children = 256 pm.max_requests = 1024 request_terminate_timeout = 10 request_slowlog_timeout = 5 slowlog = /data1/var/logs/php-fpm/slow9001.log rlimit_files = 65535 rlimit_core = 0 chroot = chdir = catch_workers_output = yes pm.status_path = /php_status9001 指定配置文件的启动命令如下，同步更新加入到服务管理/etc/init.d/php-fpm2。/usr/local/php-fpm/sbin/php-fpm -y /usr/local/php-fpm/etc/php-fpm2.conf 2、启动服务查看 9001 端口以及进程 3、修改 nginx 的配置文件，增加轮
FAQ
Nginx 与 PHP-FPM 通信默认使用什么协议？
两者通过 FastCGI 协议进行通信，实现解耦与高效协作。
如何防止 PHP-FPM 进程数不足导致 502 错误？
可通过调整 FPM 子进程配置提升吞吐量，如设置 pm.max_children 为合适值，并确保 listen.backlog 足够大。
PHP-FPM 多实例部署有什么优势？
想着最大限度的利用服务器闲散的 cpu、内存、io、网络，提高单台服务器的吞吐量，避免单实例瓶颈。