Http gzip 压缩和性能

Question

我一直尝试在 Web 服务器上启用 gzip 压缩，因为它似乎具有非常低的 CPU 成本并且您获得了显着的数据传输减少。

现在我有一个没有启用 gzip 的公共服务器，有时它的 CPU 负载在大流量下相当高（主要是因为某些页面上的复杂 SQL 查询）并且阅读这篇关于启用主题的Microsoft 文章，应该考虑 CPU 负载启用 gzip 时的帐户。

客户端想要减少带宽并加快页面加载时间，但我不确定启用 gzip 会弊大于利，尽管它在其他服务器上运行良好。

根据您的经验，gzip 压缩会对 CPU 负载产生重大影响吗？

编辑：在这种情况下，我们使用的是 IIS6

Answer 1

关键问题是“压缩了多少数据？”。

如果您正在运行一个需要显着数秒才能运行的大规模数据库查询，并且结果页面有几十 Kb 长，那么压缩数据的费用将与 SQL 工作的费用完全相形见绌点在那里甚至想都没有点。与任何庞大的数据库查询相比，现代 CPU 几乎可以立即压缩数十或数百 Kb。

另一个支持压缩的因素是，正确配置的静态页面不会在每次请求时重新压缩，并且不会受益的对象（图像文件和其他预压缩文件）根本不会被 Web 服务器压缩。每个请求只需要压缩动态可能可压缩的内容。

一般来说，除非您有特定的理由不压缩，否则我建议您这样做。CPU 成本通常很小，除非您出于某种原因在低功耗设备（例如家用路由器）上运行 Web 服务器。不压缩的原因之一是使用“长轮询”技术来有效模拟服务器推送的脚本或将内容滴入浏览器以指示进度的脚本 - 动态压缩所暗示的缓冲可能导致此类请求在客户端超时一边，但通过仔细配置，您可以将它们添加到“不压缩”列表中，同时仍然压缩其他所有内容。考虑不使用动态压缩的另一个原因是它确实为每个动态请求增加了一点延迟，尽管对于大多数 Web 应用程序而言，与带宽节省相比，这种差异完全可以忽略不计。

关于由于 SQL 查询导致的 CPU 负载的旁注：这意味着这些查询的工作数据集足够小以适合 RAM（否则您的性能将受到 I/O 限制而不是 CPU 限制），这是一件好事（ Tm值）。高 CPU 负载可能只是由于您怀疑的并发查询的剪切数量，但也可能是其中一些是 SQL 分配的 RAM 和/或操作系统缓存中的表扫描对象（或者它们是其他长时间地完成他们的工作）因此可能值得记录长时间运行的查询并检查是否有任何索引改进或其他优化，您可以使用它们来减少它们操作的工作集。