如何配置 worker_connections 应对长连接与短连接混合场景的资源分配-Nginx-PHP中文网

worker_connections需按连接类型差异化调优：长连接为主时保留60%～70%余量，短连接密集型可设16384并同步调高somaxconn和tcp_tw_reuse，混合场景建议起步8192，必须与ulimit、worker_rlimit_nofile、epoll、multi_accept及keepalive_timeout协同配置，否则无效。

如何配置 worker_connections 应对长连接与短连接混合场景的资源分配

worker_connections 不是设得越高越好，尤其在长连接与短连接混合的场景下，必须兼顾连接持有时间、系统资源消耗和并发吞吐之间的平衡。关键在于让每个 worker 进程既能稳定承载大量长连接（如 WebSocket、SSE、HTTP/1.1 Keep-Alive），又能快速响应并释放短连接（如 API 查询、静态资源请求），避免 FD 耗尽或内存堆积。

区分连接类型，按需分配资源余量

长连接持续占用文件描述符（FD）和内存，而短连接虽生命周期短，但高频时会引发大量 TIME-WAIT、accept 队列溢出和上下文切换开销。因此不能简单套用“最大连接数 = worker_processes × worker_connections”来规划：

对长连接为主的服务（如实时消息网关），建议保留 60%～70% 的 worker_connections 用于维持活跃连接，其余留给新连接接入和上游通信
对短连接密集型服务（如 RESTful API 网关），可适当提高 worker_connections（如 16384），但必须同步调高 net.core.somaxconn 和 net.ipv4.tcp_tw_reuse，防止监听队列丢包和端口耗尽
混合场景推荐起步值为 8192，再根据压测中 active connections 与 reading/writing/waiting 的比例动态调整：waiting 长期高于 active 的 30%，说明连接复用率低，需检查 keepalive_timeout 和 upstream keep-alive 设置

配套调优 events 模块参数

仅改 worker_connections 不起作用，必须配合事件模型与连接调度策略：

use epoll; —— Linux 下强制启用高效 I/O 多路复用，避免 select/poll 性能衰减
multi_accept on; —— 允许单次事件触发时尽可能多地 accept 新连接，减少短连接排队延迟
accept_mutex on; —— 在多 worker 场景下避免惊群，防止长连接空闲时仍频繁争抢 accept 锁
keepalive_timeout 15s; —— 比默认 65s 更激进；长连接业务可单独在 location 中延长，避免全局设置拖累短连接回收

同步收紧系统级资源限制

worker_connections 生效的前提是底层资源不卡脖子：

单进程 FD 上限：确保 ulimit -n ≥ worker_connections，且 worker_rlimit_nofile 设为相同或略高（如 8192 → 10000）
系统总句柄池：fs.file-max 应 ≥ worker_processes × worker_rlimit_nofile × 1.2（预留日志、缓存、上游连接等开销）
TCP 监听队列：net.core.somaxconn = 65535，避免高并发短连接 burst 时丢 SYN 包
TIME-WAIT 控制：net.ipv4.tcp_tw_reuse = 1 + net.ipv4.tcp_fin_timeout = 30，加速端口回收，特别利于短连接突发场景

验证与观测要点

配置生效后，不能只看 nginx -t 或启动成功，要通过运行态指标确认是否真正适配混合负载：

用 nginx -s reload 后执行 ss -s 查看 socket 统计，重点关注 total、tcp、tw（TIME-WAIT 数量）是否突增异常
访问 /nginx_status（需开启 stub_status）观察 Active connections 与 Reading/Writing/Waiting 的分布：Waiting 长期 > 80% 表示连接积压，可能是 upstream 响应慢或 keepalive 复用未生效
用 cat /proc/$(pgrep nginx)/limits | grep "Max open files" 确认 worker 进程实际加载的 nofile 限制是否符合预期
压测时关注错误日志中的 "accept() failed (24: Too many open files)" 或 "connect() failed (11: Resource temporarily unavailable)"，这是资源未对齐的直接信号