关键不是“猛踩油门”，而是构建可复现、可观测、可归因的压测链路；需用wrk多线程压测（如-wrk -t8 -c4000 -d180s --latency），同步观测qps、p50/p95延迟及cpu/网络/内核指标，避免ab瓶颈与本地回环失真。
要测试 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 / CPS / Throughput：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: 123456是否接近net.core.somaxconn；dmesg | tail检查有无TCP: too many of 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 80 backlog=65535 - 查看 TIME_WAIT 状态：
ss -s | grep "time-wait"，若超 3 万且持续增长，需调大net.ipv4.tcp_max_tw_buckets并启用net.ipv4.tcp_tw_reuse = 1
区分静态与动态场景，避免缓存干扰
- 测试静态资源（如 2KB HTML）时，每次压测前执行
sync && echo 3 > /proc/sys/vm/drop_caches清空页缓存，确保测的是真实 IO 路径 - 测试动态接口时，后端需返回固定响应（如 mock JSON），关闭其日志、DB 连接池、缓存，让瓶颈只落在 Nginx 代理层或 upstream 调度逻辑上
不复杂但容易忽略。
