压测brotli需统一环境并对比qps、平均延迟及p99等指标：启用accept-encoding: br、禁用gzip、固定url与压测机，用wrk/hey执行前后对比，结合nginx日志与stub_status交叉验证，排除后端瓶颈、缓存未命中、cpu饱和及tls握手干扰。
直接用压测工具跑相同请求，对比 QPS 和平均延迟变化，就能看出 Brotli 对吞吐量的真实影响。重点不是“压得更小”，而是“单位时间能处理多少请求、用户等多久”。
压测前必须统一环境与指标口径
避免结果被干扰，需确保两次压测条件完全一致：
- 使用同一台压测机（或同配置多台），禁用本地缓存和代理
- 目标 URL 固定（如 /main.js 或 /api/v1/data），且该资源在 Nginx 中明确匹配 brotli_types
- 客户端请求头强制带上 Accept-Encoding: br（Brotli 仅在 HTTPS 下协商生效，HTTP 请求不会触发）
- 关闭其他压缩（如临时注释掉 gzip on），防止双压缩竞争缓冲区或误判收益
- 记录核心指标：QPS、平均响应时间（latency）、P95/P99 延迟、错误率、Nginx worker 进程 CPU 使用率（top -p $(pgrep nginx)）
推荐压测方法与关键观察点
不用复杂平台，wrk 或 hey 就够用。例如：
- 启用 Brotli 后运行：wrk -t4 -c1000 -d30s --header="Accept-Encoding: br" https://yoursite.com/app.js
- 关闭 Brotli（brotli off + 重载）后，用完全相同的命令再跑一次
- 重点关注三组数据变化：QPS 是否上升、平均延迟是否下降、高分位延迟（如 P99）是否收敛
- 若 QPS 上升但 P99 延迟明显拉长，说明 Brotli 在高并发下触发了 CPU 瓶颈（尤其 brotli_comp_level > 6 时）
结合日志与系统指标交叉验证
压测不能只看工具输出，要和服务器端数据对齐：
- 开启带 $request_time 和 $body_bytes_sent 的自定义日志格式，分别采集两轮压测的 access_log
- 用 awk 统计平均响应体大小：awk '{sum += $5; n++} END {print sum/n}' brotli_on.log —— 应比关闭时低 17%–25%
- 检查 $request_time 分布：awk '$6 > 0.5' brotli_on.log | wc -l 对比关闭时数量，看慢请求是否减少
- 同步监控 nginx_stub_status（需开启）中的 Reading/Waiting/Active 连接数，若 Waiting 持续高位，说明压缩耗时正在阻塞事件循环
识别典型失真场景
以下情况会导致压测结果“看似提升、实则不可靠”：
- 后端瓶颈未解除：若 $upstream_response_time 占 $request_time 80% 以上，Brotli 压缩几乎不影响总延迟，QPS 变化来自后端波动
- 静态资源未命中：压测路径若走的是动态接口（如含 query 参数的 /api?ts=xxx），而 Nginx 缓存未生效，压缩收益会被后端 RT 掩盖
- CPU 已饱和：压测中 worker 进程 CPU 超过 90%，此时提升 QPS 反而会推高延迟，应先调低 brotli_comp_level 至 4–5
- HTTPS 握手干扰：若未启用 ssl_session_cache 或仍支持 TLS 1.0/1.1，握手开销可能抵消压缩收益，需单独用 openssl s_time 测握手耗时
