测试worker_connections在突发流量下的动态响应，关键在于验证其是否被系统级资源、内核队列和事件机制共同支撑；必须对齐用户级ulimit、Nginx级worker_rlimit_nofile及内核net.core.somaxconn三层限制，并用wrk模拟短连接洪峰，配合multi_accept on、accept_mutex off、keepalive_timeout 0等events调优实现快速响应。
测试 worker_connections 在突发流量下的动态响应，关键不是看它“能不能设大”，而是验证它在真实短连接洪峰中是否能被系统级资源、内核队列和事件处理机制共同支撑住——设高了没用，设低了直接丢连接。
先确认三层限制是否真正对齐
压测前必须确保以下三项一致生效，否则所有结果都失真：
-
用户级 fd 上限：检查
ulimit -n输出值，应 ≥worker_processes × worker_connections；在/etc/security/limits.conf中为 nginx 用户设 soft/hard nofile 65536 -
Nginx 进程级声明：主配置块加
worker_rlimit_nofile 65536，reload 后执行cat /proc/$(pgrep nginx)/limits | grep "Max open files"确认生效 -
内核连接队列：
net.core.somaxconn必须 ≥worker_connections，写入/etc/sysctl.conf并运行sysctl -p；同时 Nginx 的listen指令要显式带backlog=65535
用 wrk 模拟真实短连接突增
避免 ab 的不可控性，用 wrk 强制新建连接，贴近秒杀类场景：
- 基础命令：
wrk -t4 -c8192 -d30s --timeout 5s -H "Connection: close" http://127.0.0.1/（-H "Connection: close"确保每请求新建 TCP 连接） - 逐步加压：从
-c4096 → -c16384 → -c32768，每次观察nginx stub_status中Active connections是否线性增长 - 临界信号：
Active接近预设上限时，若Waiting骤降、Reading显著升高，或出现大量accept() failed (24: Too many open files)错误日志，说明连接层已卡住
实时观测连接生命周期与内核反馈
不能只盯 Nginx 日志，要穿透到系统层看真实行为：
- 查 ESTAB 连接总数：
ss -s | grep tcp:，确认inuse值是否稳定在worker_processes × worker_connections附近，而非持续飙升 - 抓 TIME_WAIT 泄漏：
netstat -ant | awk '{print $6}' | sort | uniq -c | grep TIME_WAIT，若超 3 万且不回落，需开启net.ipv4.tcp_tw_reuse = 1 - 抽样 worker fd 占用：
lsof -p $(pgrep nginx | head -1) | wc -l，数值应随并发增长而上升，但不超过worker_connections × 1.2
配合 events 块关键开关做响应调优
光有容量不够，还得让 Nginx “接得快、分得匀”：
- 启用
multi_accept on;：让单次 epoll 循环尽可能多地 accept 新连接，缓解突发排队 - 关闭
accept_mutex off;：多 worker 场景下减少锁争抢（尤其搭配reuseport时效果明显） - 禁用长连接：
keepalive_timeout 0;，防止短连接业务中 fd 被空占 - 显式指定
use epoll;：避免回退到 select/poll 的 1024 硬限制
