测试nginx缓存有效期需通过压测对比后端请求数变化：关闭缓存时30秒内2980次请求；设1分钟有效期降为50–80次，10分钟仅5–10次；结合proxy_cache_lock、日志统计与文件时间戳验证过期行为及命中率。
测试 Nginx 缓存有效期对服务器压力的影响，核心是观察不同缓存时长下后端请求数、响应延迟和缓存命中行为的变化。不能只看配置是否生效，而要通过可测量的系统反馈验证“过期时间设短了会不会压垮后端”“设长了会不会返回陈旧数据”。
用压测工具对比前后端请求量变化
这是最直接反映压力差异的方式：
- 先统一关闭缓存（注释掉 proxy_cache 相关指令），用 wrk -t4 -c100 -d30s http://your.site/api 压测 30 秒，记录后端 access.log 中该接口的总请求数（比如 2980 次）
- 再开启缓存，分别设置 proxy_cache_valid 200 1m 和 proxy_cache_valid 200 10m，每次 reload 后用相同参数重跑压测
- 对比发现：1 分钟有效期下，后端请求数可能降到 50–80 次（每分钟刷新一次）；10 分钟下可能仅 5–10 次——说明更长有效期确实大幅降低回源频率
- 注意排除干扰：确保测试期间没手动清理缓存，且客户端不带 Cache-Control: no-cache 或 Pragma: no-cache
监控过期瞬间的并发回源行为
缓存集体过期会引发“失效风暴”，重点看它是否真实发生：
- 把缓存设为固定值如 proxy_cache_valid 200 60s，并启用 proxy_cache_lock on 和 proxy_cache_use_stale updating
- 在过期前 5 秒发起一批并发请求（例如 50 个），用 tail -f /var/log/nginx/access.log 观察后端日志
- 若只看到 1 条新请求记录，其余响应头中 X-Cache-Status 是 UPDATING 或 STALE，说明锁机制生效，未造成雪崩
- 若看到几十条同时打到后端的日志，则说明 proxy_cache_lock 未生效或 key 设计不合理（比如含随机参数导致 key 分裂）
检查缓存文件生命周期与磁盘落地情况
确认缓存真的按设定时间过期，而不是被 inactive 清理或权限问题卡住：
- 进入 proxy_cache_path 目录（如 /var/cache/nginx），执行 find . -name '*' -type f -printf '%T@ %p\n' | sort -n | tail -5
- 观察时间戳：如果缓存刚写入就立刻消失，可能是 inactive=10s 太小，或磁盘满、权限错误（查 error.log 看是否有 Permission denied）
- 用 stat 查单个缓存文件，对比其 mtime 和你预期的过期时间是否吻合（注意：mtime 是写入时间，不是过期时间；过期判断由 Nginx 内部逻辑完成，但文件存在是前提）
- 配合 add_header X-Cache-Status $upstream_cache_status，在浏览器里反复刷新，看从 HIT 到 EXPIRED 的切换是否发生在你设的时长附近（允许几秒误差）
结合日志统计命中率与过期分布
长期运行中看有效期是否带来预期的稳定性：
- 在 access.log 中添加日志格式： log_format cache '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_cache_status"'
- 每小时跑一次脚本：awk '$12=="HIT"{h++} $12=="MISS"{m++} $12=="EXPIRED"{e++} END{print "HIT:"h,"MISS:"m,"EXPIRED:"e}' /var/log/nginx/access.log
- 如果 EXPIRED 数量在整点附近突增，说明用了固定 TTL；如果较平滑，则说明用了随机偏移或 stale-while-revalidate 类策略
- 命中率持续低于 60% 且 EXPIRED + MISS 占比高，大概率是缓存时间设得太短，或 key 过于分散（比如含用户 Cookie 或时间戳参数）
