worker_connections是资源上限阈值而非性能拐点参数，其合理值取决于业务连接模型与系统资源能力，需通过压测验证是否能稳定承载峰值连接、不触发拒绝或fd耗尽，并确保系统级、用户级、nginx级三层限制对齐。
先明确你要测什么
worker_connections 不是越大越好，也不是越小越省。它的合理值必须满足：能兜住业务峰值连接需求 + 留出缓冲余量 + 不突破系统限制。压测目标不是找一个最大数字，而是验证：
- 配置值是否真被生效（proc limits 是否对齐）
- 连接数增长时，Active connections 是否线性上升、无突降
- 达到预设值 70%～80% 时，延迟、QPS、CPU %us 是否开始劣化
- 是否出现 accept() failed (24: Too many open files) 或 connection reset
压测前必须对齐三层限制
否则压测结果完全失真。三者取最小值，才是真实瓶颈：
- 系统级：/proc/sys/fs/file-max ≥ worker_processes × worker_connections × 1.3
- 用户级：ulimit -n（运行 nginx 的用户）≥ worker_processes × worker_connections
- Nginx 级：worker_rlimit_nofile ≥ worker_connections（且 reload 后需用 cat /proc/$(pgrep nginx)/limits 验证）
缺一不可。常见失败就是只改了 nginx.conf 里的 worker_connections，却忘了改 limits.conf 或 sysctl.conf。
用 wrk 做定向连接层压测
不推荐 ab，wrk 更可控、支持长连接、能精准模拟连接池压力：
- 先跑基准：wrk -t4 -c2048 -d30s http://127.0.0.1/（-c 值略高于单 worker 上限）
- 逐步加压：-c 从 4096 → 8192 → 16384，每次观察 stub_status 中 Active connections 和 ss -s 输出的 ESTAB 数
- 重点看临界点：当 Active 接近 worker_processes × worker_connections，且出现大量 Waiting 或 Reading 升高、P95 延迟跳升 >30%，说明连接池开始饱和
注意：-c 值应 ≥ worker_processes × worker_connections 才可能打满；若 -c=10000 但 Active 始终卡在 6000，说明瓶颈不在 worker_connections，可能是 ulimit 或 file-max 不足。
结合业务连接模型反推合理值
静态服务、短连秒杀、长连 WebSocket，对 worker_connections 的消耗逻辑完全不同：
- HTTP/1.1 短连接（如 H5 秒杀）：连接建得快、断得快，fd 消耗集中在 accept 阶段，建议设 8192～16384，同时调大 net.core.somaxconn 和启用 tcp_tw_reuse
- HTTP/1.1 长连接（App 保活）：每个客户端占 1～2 个 fd，但长期持有，建议 4096～8192，重点调 keepalive_timeout（15～30s）和 keepalive_requests（100～1000）
- HTTP/2 或 gRPC：复用强，连接数大幅下降，可设 32768+，但需确保 worker_rlimit_nofile 和内存充足（单连接内存开销更高）
压测时务必匹配真实模型：短连压测用 wrk -H "Connection: close"；长连压测必须加 -H "Connection: keep-alive" 并用 -k 参数启用 keepalive。
