我一直尝试在 Web 服务器上启用 gzip 压缩，因为它似乎对 CPU 的要求很低，并且可以显著减少数据传输。
现在我们有一个没有启用 gzip 的公共服务器，有时在流量大的情况下它的 CPU 负载会很高（主要是因为某些页面上的 SQL 查询很复杂），并且读取这篇微软文章关于启用，启用 gzip 时应考虑 CPU 负载。
客户希望减少带宽并加快页面加载时间，但我不确定启用 gzip 是否弊大于利，尽管它在其他服务器上运行良好。
根据您的经验，gzip 压缩会对 CPU 负载产生重大影响吗？
编辑：在这种情况下，我们使用的是 IIS6
答案1
关键问题是“压缩了多少数据？”。
如果您正在运行一个需要花费数秒才能运行的大型数据库查询，并且生成的页面只有几十 KB，那么压缩数据的开销与 SQL 工作开销相比将完全相形见绌，甚至无需考虑这一点。与任何大型数据库查询相比，现代 CPU 几乎可以立即压缩数十或数百 KB。
另一个有利于压缩的因素是，如果配置正确，静态页面不会在每次请求时重新压缩，并且不会受益的对象（图像文件和其他预压缩文件）根本不会被 Web 服务器压缩。只有动态的可能压缩的内容才需要在每个请求上进行 gzip 压缩。
一般来说，除非你有特殊原因不是压缩，我建议这样做。CPU 成本通常很小，除非您出于某种原因在低功耗设备（例如家用路由器）上运行 Web 服务器。不压缩的一个原因是使用“长轮询”技术高效模拟服务器推送的脚本或将内容滴灌到浏览器以指示进度的脚本 - 动态压缩隐含的缓冲可能会导致此类请求在客户端超时，但通过仔细配置，您可以将它们添加到“不压缩”列表中，同时仍然压缩其他所有内容。考虑不使用动态压缩的另一个原因是它确实会给每个动态请求增加一点延迟，尽管对于大多数 Web 应用程序来说，与带宽节省相比，这种差异完全可以忽略不计。
关于 SQL 查询导致的 CPU 负载的附注：这意味着这些查询的工作数据集足够小，可以放入 RAM 中（否则您的性能将受到 I/O 限制而不是 CPU 限制），这是一件好事。高 CPU 负载可能只是由于您怀疑的并发查询数量过多，但也可能是其中一些是 SQL 分配的 RAM 和/或操作系统缓存中的表扫描对象（或者它们以其他方式绕远路完成工作），因此可能值得记录长时间运行的查询并检查是否有任何索引改进或其他优化可用于减少它们操作的工作集。
答案2
启用 GZIP 压缩不会显著影响您的 CPU 负载。以防万一，您还应该检查内存消耗，因为现在您需要在发送之前在内存中缓冲更多数据（除非 GZIP 压缩在没有纯文本缓冲的情况下发生）。有时，缓存破坏可能会导致 Web 服务器速度严重下降。