压测缓存需模拟真实命中路径，重点观察响应时间、缓存命中率和后端请求量趋势；配置Nginx proxy_cache并用X-Cache-Status验证HIT/MISS，结合wrk高并发压测同一URL，同步监控命中率≥95%、后端请求数趋近0及P99延迟。
直接用压测工具模拟真实缓存命中路径，重点观察响应时间、缓存命中率和后端请求量三组指标的变化趋势，而不是只看 QPS 数字。
准备可验证的缓存环境
确保 proxy_cache 确实生效，避免“以为缓存了，其实没缓存”：
- 配置明确的缓存路径和 key，例如：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:50m inactive=60m;proxy_cache_key "$scheme$request_method$host$request_uri"; - 在 location 中启用缓存并设置有效时间：
proxy_cache my_cache;<br>proxy_cache_valid 200 302 10m;<br>proxy_cache_use_stale error timeout updating;
- 加响应头方便验证：
add_header X-Cache-Status $upstream_cache_status;
压测时通过X-Cache-Status值（HIT / MISS / BYPASS）确认缓存行为
用 wrk 或 ab 模拟高并发请求
推荐使用 wrk（支持长连接、脚本化、低开销），命令示例：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
wrk -t4 -c1000 -d30s --latency "http://your-domain.com/static/image.jpg"
-
-t4：启动 4 个线程（匹配 CPU 核心数） -
-c1000：维持 1000 并发连接（覆盖预期缓存连接池） -
-d30s：持续压测 30 秒，足够观察缓存预热和稳定态 - 务必对同一个 URL发起请求（保证 key 一致，触发 HIT）
监控关键性能维度
单看吞吐量（QPS）容易误判，必须同步采集以下数据：
-
缓存命中率：从 Nginx access log 或实时响应头统计
X-Cache-Status: HIT占比。理想高并发下应 ≥95% -
后端请求量：在 upstream server 上用
ss -ant | grep :8080 | wc -l或 Prometheus + nginx-exporter 查看实际转发请求数。命中缓存后该值应趋近于 0 -
延迟分布：wrk 输出中的
Latency Distribution（如 99% -
Nginx worker 状态：
nginx -s status（需启用 stub_status）或curl http://localhost/nginx_status，关注Reading/Waiting连接数是否异常堆积
对比测试不同缓存策略
做两轮压测，隔离变量：
-
基准组：关闭 proxy_cache（注释掉
proxy_cache相关指令），记录 QPS 和平均延迟 - 缓存组：开启 cache，保持其他配置一致，再次压测
- 计算提升幅度：若基准组 QPS=1200、延迟=85ms，缓存组 QPS=9600、延迟=8ms，则吞吐提升 7 倍，延迟降低 90%，说明缓存有效分担了压力
