最可靠压测需综合qps、响应耗时、压缩率与资源类型：固定nginx配置（worker_processes auto、worker_cpu_affinity）、统一软硬件环境，用25kb html/92kb js/125kb json真实资源，动态压缩（禁用gzip_static），对比level 3/6/8三档，每轮3分钟，同步监控cpu、request_time、gzip_ratio及响应头有效性。
直接压测是最可靠的方式，但不能只看 CPU 百分比——得结合 QPS、响应耗时、压缩率和资源类型一起看。
准备真实可比的测试环境
确保压测前关闭无关服务，固定 Nginx worker 进程数（建议 worker_processes auto），并绑定 CPU 核心（worker_cpu_affinity）避免调度抖动。用相同硬件、相同内核版本、相同 OpenSSL 和 zlib 版本，否则压缩耗时不可比。
关键点：
- 压测文件必须是典型业务资源：一个 25KB 的 HTML + 一个 92KB 的 JS + 一个 125KB 的 JSON 响应（模拟压测中暴露问题的真实大小）
- 禁用 gzip_static on，确保全程走动态压缩，排除预压缩干扰
- 所有测试轮次统一开启 gzip_vary on 和 gzip_proxied any，避免代理层缓存污染结果
- 用 curl --compressed 或 wrk/jmeter 模拟真实浏览器请求头：
Accept-Encoding: gzip
分三级压缩做对比压测
别只试 level 6。按实际收益曲线，重点对比三档：
- Level 3：适合 API 网关，压缩率约 40%–45%，CPU 占用温和，QPS 稳定性高
- Level 6：Web 页面主力档，HTML/CSS/JS 压缩率 65%–75%，CPU 开销可控，是多数场景的平衡起点
- Level 8：仅作对照，压缩率提升不足 1%，但 CPU 耗时常翻 2–3 倍，QPS 反降
每轮压测持续 3 分钟，用 top -p $(pgrep nginx) 或 pidstat -u 1 实时抓取 worker 进程 CPU 使用率；同时记录 Nginx access log 中的 $request_time 和 $gzip_ratio（需提前在 log_format 中加入）。
看三项核心指标，而非单一数值
单看“CPU 用了 85%”没意义。要同步观察：
- QPS 是否随 CPU 上升而线性增长？ 若 CPU 从 60% → 95%，QPS 却只涨 5%，说明已进入压缩瓶颈
- 平均 request_time 是否明显拉长？ Level 8 下若 TTFB 从 8ms 升至 22ms，说明压缩阻塞了响应队列
- $gzip_ratio 是否显著提升？ 同一 JS 文件：level 6 达 2.82，level 8 仅到 2.84，说明边际收益归零
实测案例：某 Web 服务在 4C 机器上，level 6 时 QPS=82k，CPU=78%，平均延迟 9.2ms；切到 level 8 后，QPS 降至 63k，CPU 冲到 96%，延迟跳到 18.7ms——压缩成了性能负资产。
验证是否真走压缩路径
压测中随时抽查返回头，确认不是“配置写了但没生效”：
- 执行：
curl -I -H "Accept-Encoding: gzip" https://test.example.com/app.js - 检查响应头是否含：
Content-Encoding: gzip和Vary: Accept-Encoding - 再用
curl -s --compressed https://... | wc -c对比未压缩体积，算出真实压缩比
如果返回头没有 Content-Encoding，或 gzip_types 漏配了 application/javascript，所有压测数据都无效。
