测试Nginx高并发吞吐性能的核心是构建可复现、可观测、可归因的压测链路，而非盲目堆并发；必须用wrk替代ab（ab超2000并发即成瓶颈），配合--latency观察P50/P95延迟比值，同步监控QPS、CPU负载方差及内核连接队列等指标。
测试 Nginx 在高并发下的吞吐性能，核心不是堆高并发数，而是构建一条可复现、可观测、可归因的压测链路。真实瓶颈往往不在 Nginx 本身，而在连接调度、内核参数、CPU 调度或后端协同环节，仅看 QPS 容易误判。
用 wrk 替代 ab 进行真实并发压测
ab 工具在并发超过 2000 后会因单线程设计成为性能瓶颈，无法反映 Nginx 真实能力。wrk 支持多线程、长连接和细粒度延迟统计，是唯一推荐的压测工具：
- 典型命令：wrk -t8 -c4000 -d180s --latency http://nginx-ip/（8 线程、4000 并发、3 分钟，必须加 --latency）
- 重点关注 P50/P95/P99 延迟分布：若 P95/P50 比值 > 4，说明存在明显长尾问题
- 避免使用 127.0.0.1 或跨公网压测；客户端与 Nginx 应部署在同一局域网，最好走万兆直连，消除网络层失真
同步观测三类关键指标
吞吐与延迟必须结合系统状态交叉验证，缺一不可：
- QPS 与带宽利用率：wrk 输出的 Requests/sec 是基础，但需配合 iftop -P 80 或 nethogs 查看网卡实际吞吐是否达 90%+，判断是否真打满
- 延迟跳变归因：P95 延迟突增超 30%，大概率是 worker 调度不均或某后端拖累；用 htop 观察各 CPU 核心负载方差，若差异超 40%，检查 worker_cpu_affinity auto 是否生效
- 内核级指标：压测中执行 vmstat 1 关注 cs（上下文切换）、r（运行队列）；用 ss -s 看 total 连接数是否逼近 net.core.somaxconn；用 dmesg | tail 检查有无 TCP orphaned sockets 报错
确认高压是否真正触达 Nginx 内核层
很多“高并发”其实卡在系统限制上，而非 Nginx 配置：
- 文件描述符：执行 ulimit -n，确保 ≥ worker_processes × worker_connections × 1.5，否则会出现 accept() failed (24: Too many open files)
- 连接队列：sysctl net.core.somaxconn 和 net.core.netdev_max_backlog 均应 ≥ 65535；Nginx listen 指令中需显式配置 backlog=65535
- TIME_WAIT 控制：ss -s | grep "time-wait" 若持续超 3 万，需调大 net.ipv4.tcp_max_tw_buckets 并启用 net.ipv4.tcp_tw_reuse = 1
区分静态与动态场景，排除缓存干扰
测试前务必明确目标：
- 测静态资源吞吐：关闭所有 proxy_pass，用 sendfile on + 大文件响应，观察零拷贝效果
- 测反向代理性能：后端服务需同样调优，避免后端成瓶颈；建议用 mock server（如 mockoon）统一响应体，隔离变量
- 禁用浏览器或 CDN 缓存，所有请求带唯一 query 参数（如 ?ts=123456），确保每次请求真实穿透 Nginx
