开启Gzip后Nginx静态资源QPS略降7%，但每请求带宽消耗降至1/3.5，txkB/s下降71%，本质是以少量CPU换大幅网络传输节省；压测须统一文件、网络、缓存、配置及工具参数。
开启 Gzip 压缩后，Nginx 静态资源的吞吐量（Throughput）通常不会显著提升，甚至可能小幅下降，但单位带宽承载的请求数会明显上升——本质是用少量 CPU 换取大幅降低的网络传输量。压测时若只看 QPS 或 RPS，容易误判效果；真正反映压缩价值的指标是 txkB/s（每秒发送字节数）与 QPS 的比值，即“每请求平均带宽消耗”。
压测前必须统一基准条件
对比才有意义。以下 5 项必须保持一致：
- 使用完全相同的静态文件（如一个 26KB 的 index.html），且仅测试该文件，排除后端逻辑和动态内容干扰
- 测试机与 Nginx 服务器处于同一局域网，禁用公网路由、NAT 和中间代理
- 每次运行 wrk 或 ab 前执行
sync && echo 3 > /proc/sys/vm/drop_caches，清空页缓存、目录项缓存和 inode 缓存 - Nginx 配置中关闭日志写入（
access_log off）、禁用 SSL（避免 TLS 开销干扰）、启用sendfile on和tcp_nopush on - 客户端工具参数固定：wrk 示例为
wrk -t4 -c400 -d30s http://nginx-ip/index.html；ab 示例为ab -n 10000 -c 400 http://nginx-ip/index.html
压缩前后核心指标变化规律
以典型 26KB HTML 文件为例（实测数据来自 2026 年多轮压测）：
- 未开启 Gzip：QPS ≈ 18,500，平均响应大小 26KB，txkB/s ≈ 481,000 KB/s（≈ 3.85 Gbps）
- 开启 Gzip（level 6）：QPS ≈ 17,200（↓7%），平均响应大小降至 8KB，txkB/s ≈ 137,600 KB/s（≈ 1.1 Gbps，↓71%）
- CPU 使用率从 35% 升至 58%，软中断（si）无明显增长，说明压缩未引发调度瓶颈
- 延迟 P99 从 12ms 升至 15ms，仍在毫秒级可控范围
结论很清晰：吞吐量（QPS）略降，但带宽效率翻了近 3.5 倍。当网卡接近千兆满载（125 MB/s）或 CDN 流量计费敏感时，这个优化直接决定扩容成本。
配置要点与避坑提醒
不是开了 gzip on 就万事大吉，这些细节决定压测结果是否可信：
-
必须显式声明
gzip_types：默认只压缩 text/html，JS/CSS/JSON 等需手动加入，例如gzip_types text/css application/javascript application/json; -
gzip_min_length 1000是黄金值：小于 1KB 的文件压缩后反而更大（zlib 头部开销+低熵压缩失效），压测中若混入大量小图标（如 200B favicon.ico），会拉低整体压缩收益 -
禁用
gzip_vary可提升缓存命中率，但需确保 CDN 或反向代理层能正确识别 Accept-Encoding；压测时建议先关掉，避免 Vary 导致重复缓存 - 不要在 location 块里反复开关 gzip，易引发配置继承混乱；推荐在 http 块全局开启，用 map 按 UA 动态调级（如移动端设 level 4）
什么时候不该压这个指标？
如果你的场景满足以下任一条件，带宽压测和压缩优化优先级应降低：
- 静态资源本身已预压缩（如构建产物含 .gz 文件 +
gzip_static on），此时 Nginx 不实时压缩，CPU 几乎零开销，带宽节省更彻底 - 服务主要瓶颈在磁盘 IO（如机械硬盘 serving 大量小文件），此时压缩对 QPS 影响微乎其微，优化重点应是 open_file_cache 和 SSD 升级
- 客户端普遍不支持 gzip（如老旧嵌入式设备），或 Accept-Encoding 头被上游网关强制抹除
真实环境里，压缩的价值不在“压出更高 QPS”，而在让有限带宽跑更多用户、更低延迟交付、更少流量支出。盯紧 txkB/s 和单请求带宽成本，比只刷 QPS 数字更有实际意义。
