gzip压缩级别改变后吞吐下降怎么办

Go 里把 gzip 级别调高后吞吐下降，通常不是“gzip 失效”，而是压缩器用更多 CPU 换取更小的输出。先把一次请求拆成压缩耗时、压缩后字节数、网络写入耗时和端到端耗时，再决定级别；如果 CPU 已经是瓶颈，继续追求更小的文件只会让整体吞吐更低。

Go 官方文档：https://pkg.go.dev/compress/gzip

本文只讨论标准库 compress/gzip 的工程取舍。图中的框和连线都是静态说明图，不是本机压测截图，也不代表某个固定数据集的性能结果。

先判断吞吐下降是不是 CPU 预算被吃掉

gzip.NewWriterLevel 接受 flate.BestSpeed 到 flate.BestCompression 的级别，也支持默认、无压缩和 HuffmanOnly。级别越偏向压缩率，通常需要更多匹配搜索和编码工作，但“更小”不一定能抵消 CPU 代价，尤其是服务端本来就接近 CPU 上限时。

可以先按下面的方向读指标：

不要用单次文件大小推断吞吐。压缩率受文本重复度、块大小和请求形态影响；应固定输入样本与并发条件，分别记录压缩 CPU 时间、输出字节和总耗时。

把压缩级别和 writer 生命周期分开

级别解决的是“压缩器愿意花多少计算量”，生命周期解决的是“缓冲数据什么时候交给下游”。这两个因素混在一起时，很容易把 Flush 或遗漏 Close 的问题误判为级别问题。

package main

import (
	"compress/flate"
	"compress/gzip"
	"io"
)

// writeGzip 按调用方选择的级别写出完整 gzip 数据。
func writeGzip(dst io.Writer, src []byte, level int) error {
	// NewWriterLevel 会检查级别；错误应返回给上层，不要静默改用另一档。
	zw, err := gzip.NewWriterLevel(dst, level)
	if err != nil {
		return err
	}
	// Close 会刷新缓冲并写入 gzip 尾部；只调用 Flush 不能替代它。
	if _, err = zw.Write(src); err != nil {
		_ = zw.Close() // 写入失败时仍尝试释放压缩器资源。
		return err
	}
	return zw.Close()
}

var _ = flate.DefaultCompression // 示例中由策略层传入具体级别。

对文件或完整 HTTP 响应，常见起点是 flate.DefaultCompression；CPU 紧张时可比较 BestSpeed，带宽成本很高且 CPU 还有余量时再比较更高的级别。NoCompression 适合已经压缩过的输入或不值得再压缩的内容，HuffmanOnly 不是“更快的通用高压缩档”，它只做 Huffman 编码，适用范围更窄。

频繁 Flush 为什么会让小响应更慢

Flush 会把当前压缩数据推给底层 writer，适合压缩网络协议需要尽快让对端拿到一个可读片段的场景，但每写一小块就 Flush 会减少压缩器的连续工作空间，并增加写调用和协议开销。普通文件导出或一次性响应，通常让压缩器累积数据，最后用 Close 完成收尾更合理。

如果必须流式输出，可以用业务消息边界来决定 Flush，而不是用循环次数硬编码。排查时把“改级别”和“改 Flush 频率”分成两次实验，否则即使吞吐恢复，也无法知道真正的原因。

用真实负载选档，不要把最高压缩率当默认答案

建议先固定同一批输入、并发数和下游环境，比较四个维度：压缩 CPU 时间、压缩后字节数、端到端延迟和单位时间完成量。只有当更高的级别减少了足够多的传输成本，且没有让 CPU 或尾延迟成为新瓶颈，它才值得保留。

writer 可以通过 Reset 复用到新的底层输出，但复用对象应由单个请求或明确的串行所有权管理；不要把一个正在写入的 gzip writer 在多个请求间共享。每个请求都要有独立的收尾路径，错误时也要保留真实错误，不用“自动降级”掩盖配置问题。

• CPU 先满：优先比较 BestSpeed 与 DefaultCompression。
• 带宽先满：比较更高一级能否显著减少字节，同时观察 CPU 和延迟。
• 输入已压缩：先评估 NoCompression，不要默认重复压缩。

相关问题

gzip 默认级别是不是最省 CPU？

不是。默认级别是通用折中，不等于最快。是否更合适要看输入和系统瓶颈；CPU 紧张时应把 BestSpeed 纳入同条件对比。

只调用 Flush 不调用 Close 可以吗？

不建议。Close 负责刷新未写出的缓冲并写入 gzip 尾部；完整输出必须把它作为资源收尾动作。

最终判断可以压缩成一句话：先找瓶颈，再调级别；先固定生命周期，再比较压缩率。这样才能解释吞吐变化，而不是把某个压缩档位当成所有 Go 服务的万能答案。