压测压缩性能关键在于条件控制而非简单开关，需关注真实api链路模拟、cpu软中断与gzip_buffers内存分配、动态分级压缩及预压缩优化。
直接压测压缩性能，关键不是“开不开”，而是“在什么条件下开、开多少、对谁开”。高并发下Gzip的瓶颈从来不在算法本身，而在CPU争抢、内存拷贝和响应体生成时机。下面几个实操方向比盲目加压更有效。
用真实请求链路模拟压测，别只压静态文件
很多团队用curl反复请求一个1MB的HTML做压测，结果完全失真——因为：
- 静态文件走的是零拷贝+sendfile路径，压缩过程不经过用户态缓冲区，CPU开销被严重低估
- 真实高并发场景里，80%以上是动态接口（如JSON分页），响应体在应用层拼装完成才交给Nginx，此时压缩必须完整读入内存再运算
- 建议用AB或wrk模拟带Accept-Encoding: gzip的真实API请求，后端返回5–10KB JSON，QPS拉到2万以上，观察Nginx worker进程的CPU占用率和平均响应时间拐点
监控两个核心指标，比看QPS下降更有价值
不要只盯着“QPS掉了多少”，重点盯住：
- CPU软中断占比：gzip压缩触发大量zlib调用，会显著抬高softirq时间。top里看%si列，若持续＞15%，说明压缩已成CPU瓶颈
- gzip_buffers内存分配失败次数：通过nginx -s reload后检查error.log里是否有"gzip buffer too small"或"no memory"报错。说明并发压缩请求超出缓冲区承载能力，Nginx被迫降级为单缓冲同步压缩，延迟陡增
动态分级压缩，让高并发下的CPU消耗可控
固定用gzip_comp_level 6在峰值期就是自找麻烦。参考字节跳动和阿里双11的实践：
- 对移动端UA（含微信、QQ内置浏览器）设为level 4，压缩率只比6低2%，但CPU节省35%以上
- 对IE 11及以下、旧版Android WebView，强制level 2或禁用，避免解压兼容问题引发重传
- 用map指令实现运行时判断：map $http_user_agent $gzip_level { default 6; "~*Mobile" 4; "~*Trident|MSIE" 2; }，再在gzip_comp_level中引用$gzip_level
绕过实时压缩，用预压缩降低CPU毛刺
对CSS/JS/HTML等不变资源，启用gzip_static on，提前用zopfli或pigz生成.gz文件。Nginx发现同名.gz存在就直接sendfile返回，完全跳过压缩计算。实测在QPS 5万+时，可将gzip相关CPU占用从32%压到不足3%。
