准确评估nginx优化效果需构建可复现压测闭环：统一物理隔离环境、清空系统缓存、固定静态资源、单变量调优；结合ab/wrk压测与nginx_status/top/ss等实时监控，以qps平台期、p95跳变、cpu未满但qps卡住为吞吐极限标志；用拐点对比法定量收益。
要准确评估 Nginx 优化前后的并发吞吐极限，不能只比“QPS 数值高低”，而必须构建可复现、可归因、可定位瓶颈的压测闭环。核心在于：**用同一套方法论，在相同干扰条件下，让每次测试结果真正反映配置或系统层改动带来的真实收益。**
一、压测前必须统一环境基线
环境不一致，所有对比都无意义。需强制满足以下四点：
- 物理隔离客户端与服务端：压测机和 Nginx 服务器必须分属不同物理机或容器，且在同一局域网（推荐万兆直连），避免本机资源争抢（如 CPU、网络栈、文件缓存）污染结果；
-
清空系统缓存：每次测试前执行
sync && echo 3 > /proc/sys/vm/drop_caches，清除页缓存、dentry 和 inode 缓存，排除静态文件被内核缓存导致的“虚高”响应速度； -
固定压测对象：全程使用最小静态资源（如 1KB 的
index.html），禁用 gzip、SSL、proxy_pass 等干扰项，确保瓶颈只在 Nginx 自身连接处理路径上； -
锁定观测维度：每次只调一个变量（例如仅改
worker_processes），其余配置（worker_connections、use epoll、multi_accept on）全部冻结。
二、选对工具并关注关键指标组合
单一 QPS 不足以判断吞吐极限。需同步采集三类指标，交叉验证瓶颈类型：
-
ab（Apache Bench）适合快速摸底：命令如
ab -n 20000 -c 1000 http://192.168.1.10/；重点看 Requests per second 和 Time per request (mean)，但并发超 2000 后 ab 自身易成瓶颈，不可用于极限测试； -
wrk 是主力验证工具：命令如
wrk -t4 -c4000 -d180s --latency http://192.168.1.10/；必须加--latency获取 P50/P95/P99 延迟分布——P95 突增 30%+ 是连接耗尽或调度失衡的明确信号； -
服务端同步监控不可少：测试中实时查看
nginx_status（Active connections、Reading/Writing/Waiting）、top（%us 用户态 CPU）、ss -s（已用 socket 数）、cat /proc/<pid>/limits | grep "Max open files"</pid>（确认 nofile 未触顶）。
三、识别真实吞吐极限的三个标志
极限不是“QPS 最大值”，而是系统开始失稳的拐点。出现以下任一现象，即视为当前配置下的吞吐上限：
- QPS 进入平台期或回落：并发从 3000 增至 4000 时，QPS 不升反降（例如从 38000→36500），说明资源已达饱和；
- P95 延迟跳变式升高：例如从 8ms 飙升至 45ms，同时 Waiting 连接数持续 ≥ Active connections 的 70%，表明连接队列积压严重；
-
CPU %us 未满但 QPS 卡住：若 %us 长期低于 75%，但 QPS 无法提升，则瓶颈大概率在系统层——检查
ulimit -n是否 ≥worker_processes × worker_connections × 1.5，或net.core.somaxconn是否过低。
四、用“拐点对比法”量化优化收益
不要记绝对数值，而要记录每个配置下 QPS-P95 曲线的拐点位置。例如：
- 优化前：
worker_processes 4; worker_connections 2048→ 拐点出现在并发 3200，QPS=29500，P95=32ms； - 优化后：
worker_processes auto; worker_cpu_affinity auto; worker_rlimit_nofile 100000→ 拐点移至并发 5800，QPS=51200，P95=14ms； - 结论：吞吐极限提升 73%，长尾延迟下降 56%，且拐点右移 81%，说明系统承载弹性显著增强。
不复杂但容易忽略
