Nginx缓存性能测试关键在于验证缓存是否真正生效、响应是否变快、后端是否被有效卸载，需构建缓存/非缓存对照组，同步监控Nginx层（$upstream_cache_status、延迟）、系统层（CPU、%iowait）及后端层（实际QPS），识别命中率与后端请求量是否匹配，并排查缓存key错误、磁盘I/O、inactive超时或缓冲区不足等瓶颈转移问题。
要分析 Nginx 缓存层中请求处理的性能，关键不是测“Nginx 能不能缓存”，而是验证缓存是否真正生效、响应是否变快、后端是否被有效卸载。这需要把缓存行为纳入完整的基准测试闭环里，而不是单独跑一个 ab 就完事。
明确缓存层的测试目标
缓存性能测试不是为了追求最高 QPS，而是回答三个具体问题：
- 命中缓存时，平均延迟是否显著低于未命中（比如从 80ms 降到 5ms）
- 缓存命中率是否稳定（例如持续压测 3 分钟，命中率是否 ≥95%）
- 后端服务器的请求量是否同步下降（如上游应用 QPS 从 1200 降到 50）
构造可对比的缓存/非缓存对照组
必须在同一套硬件和网络环境下，用完全相同的请求路径，分别测试两种模式：
- 缓存开启组：配置 proxy_cache + proxy_cache_valid，且确保请求头不带 Cache-Control: no-cache 或 Pragma: no-cache
- 缓存绕过组：临时在 location 块中加入 proxy_cache_bypass $arg_nocache；然后用 ?nocache=1 发起请求，强制走后端
两组使用相同 wrk 命令（如 wrk -t4 -c1000 -d120s --latency http://nginx/），只改 URL 参数，其余环境、资源、系统状态全部一致。
监控指标必须跨层对齐
单看 Nginx 日志里的 $upstream_cache_status 是不够的。要同步采集三类数据：
- Nginx 层：用 log_format 记录 $upstream_cache_status、$request_time、$upstream_response_time
- 系统层：用 pidstat 或 atop 监控 nginx worker 进程的 CPU 使用率、磁盘 I/O 等待（尤其关注 %iowait 是否突增）
- 后端层：在 upstream 服务上统计实际收到的请求数（如通过 access_log 或 Prometheus metrics）
如果 Nginx 显示 HIT 率 98%，但后端 QPS 没降，说明缓存 key 配置有误（比如 proxy_cache_key 漏了 $cookie_session，导致每个用户都生成新缓存）。
识别缓存带来的真实瓶颈转移
启用缓存后，性能瓶颈往往从后端转移到 Nginx 自身或文件系统：
- 若 QPS 不再上升、P95 延迟跳升、而 CPU 用户态（%us）仍低于 70%，检查磁盘 I/O：缓存目录是否在机械盘上？是否启用了 directio？
- 若大量 MISS 后紧跟大量 EXPIRED，可能是 inactive 时间设得太短（如仅 5m），导致缓存刚写入就被清理
- 若并发一高就出现 502，检查 proxy_buffers 和 proxy_busy_buffers_size 是否过小，无法暂存大响应体
