proxy_cache高并发吞吐极限需通过缓存生效验证（HIT≥95%且后端QPS下降）、读取稳定性（P95延迟无抖动）及I/O与锁竞争检测（%iowait>15%或CPU异常）三方面精准测定，辅以对照组、三层指标同步采集和阶梯压测。
要测清楚 proxy_cache 在高并发下的真实吞吐极限，不能只看 Nginx 返回了多快，得把缓存层“拆开来看”——确认请求真进了缓存、没绕过、没打到后端，同时观察缓存自身是否成了新瓶颈。
明确测试目标：不是测 Nginx 能扛多少并发，而是测 proxy_cache 能稳住多少 QPS 不降级
重点验证三件事：
- 缓存是否真正生效（HIT 率 ≥95%，且后端请求数同步下降）
- 高并发下缓存读取是否稳定（P95 延迟不跳变、无抖动）
- 缓存写入/淘汰是否引发 I/O 或锁竞争（CPU %us 不高但延迟飙升，或 %iowait >15%）
构造可信的缓存/非缓存对照组
必须在同一硬件、同一网络、同一请求路径下对比，仅切换缓存开关：
- ✅ 缓存开启组：启用
proxy_cache+proxy_cache_valid 200 302 10m;，确保请求头不含Cache-Control: no-cache或Pragma: no-cache - ✅ 缓存绕过组：在 location 中加
proxy_cache_bypass $arg_nocache;，用?nocache=1强制走后端 - 两组使用完全相同的 wrk 命令（如
wrk -t8 -c2000 -d180s --latency http://nginx/），只改 URL 参数，其余零改动
同步采集三层指标，缺一不可
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
单看 $upstream_cache_status 日志会误判。必须对齐以下三类数据：
-
Nginx 层：自定义 log_format 记录
$upstream_cache_status、$request_time、$upstream_response_time、$bytes_sent -
系统层：用
pidstat -p $(pgrep nginx) 1监控 worker 进程 CPU（%us）、I/O 等待（%iowait）、上下文切换（cswch/s） -
后端层：在 upstream 服务上统计实际收到的请求数（如
curl -s http://backend/metrics | jq '.http_requests_total'），确认缓存 HIT 是否真实分流
若 Nginx 显示 HIT 97%，但后端 QPS 几乎不变，大概率是 proxy_cache_key 漏了关键变量（比如没包含 $host 或 $args），导致每个请求都生成新缓存条目。
识别缓存带来的瓶颈转移
启用 proxy_cache 后，性能瓶颈常从后端转移到 Nginx 自身或磁盘：
- 若 QPS 卡在某个值不再上升，P95 延迟却陡增，而 CPU %us < 65%，优先查磁盘 I/O：
- 缓存目录是否在机械盘上？SSD 是硬要求
-
df -i看 inode 是否耗尽（小文件缓存易触发） -
iostat -x 1观察await> 20ms 或%util持续 100%
- 若 P95 延迟随并发线性增长，检查
proxy_cache_path的levels和keys_zone大小：-
keys_zone=cache_zone:100m太小会导致 key 冲突频繁淘汰 - 推荐起始值：
keys_zone=cache_zone:512m（支持约 400 万缓存项）
-
压测节奏建议：阶梯式升压 + 每轮清缓存
- 每轮压测前执行：
find /var/cache/nginx -name "*" -delete && sync && echo 3 > /proc/sys/vm/drop_caches - 并发梯度设为：500 → 1000 → 2000 → 4000（每档跑 3 分钟，取 P95 和 QPS 中位数）
- 关键拐点判断：当 P95 延迟比 P50 高出 4 倍以上，或 QPS 连续两档不增，即视为吞吐极限
不复杂但容易忽略
