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
• 缓存目录是否在机械盘上？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 连续两档不增，即视为吞吐极限

不复杂但容易忽略