【发布时间】：2013-05-24 02:56:15
【问题描述】：
浏览器解压缩平均大小网页的 gzip 服务器响应的开销是多少？
【问题讨论】：
-
说大约130万左右。它不需要精确。我只是想知道在解压过程中存在什么样的开销。
标签： performance browser compression gzip
【发布时间】：2013-05-24 02:56:15
【问题描述】：
使用带有默认参数的 gzip 的 zlib 实现。
在面向 Internet 的服务器上，至强 cpu 2.66Ghz 四核，gzip 压缩时间为 小于 0.5mS 高达 15Kb。 361Kb 是 4.50mS，1077Kb 需要 13mS
但我认为这仍然很值得，因为我们的大部分流量都是通过 wifi 或 3G 链接流出的，因此传输时间远远超过服务器延迟。
时间是用代码括起来只调用 gzip 例程并使用 nS 精度计时器来测量的，我更改了源代码来实现它。无论如何我都在测量这个，因为我试图确定缓存 gzip 是否值得内存权衡，或者 gzip 是否足够快。在我们的例子中，我认为我们会对大约 200 字节以上的所有内容进行 gzip，并积极缓存 gzip 的响应，尤其是对于较大的数据包。
（@Mark adler，感谢您编写 zlib）
【讨论】：
-
感谢您分享您的发现。你如何衡量这个？我不相信在 Web 服务器上启用 gzip 会改善用户体验，因为网络速度非常快，ping 时间为 20 毫秒。
-
这与 ping 时间无关。这是关于转移时间。
-
这个和解压问题无关。
我假设您的意思是 1.3M 未压缩。我在 2 GHz i7 的一个内核上获得大约 6 毫秒的解压时间。
如果我假设 1/3 压缩，如果不压缩，则需要传输额外的 7 Mbits。在 1 Gbit/s 链路上，这将花费超过 6 毫秒。在更典型的 10 Mbit/s 链路上为 700 毫秒。
gzip 是 HTTP 传输的一大胜利。
【讨论】：
-
7,270,127 位以 100Mbps 传输需要 8.6 毫秒。所以浏览器开销是 6ms，而做 gzip 的服务器开销是 2ms，是不是洗了？
-
不值得。通信链路是共享资源，通过它发送额外的 7M 位会影响网络上的所有用户，因此如果可以的话，您希望避免这种情况（CSMA/CD）。
-
这对我来说是个新领域。几乎我读到的所有内容都说 gzip 是双赢的，有些人谈论浏览器的第一个字节并且它不是那么好。我对网络的了解非常有限，所以我尝试使用这个计算器：calctool.org/CALC/prof/computing/transfer_time 感谢您帮助我解决这个问题...
-
如果实施得当，解压几乎不会引入延迟。在它开始传送未压缩的数据之前，您只需要通过大约 80 字节的压缩数据。
-
这应该是公认的答案。此外，@MarkAdler 您对解压延迟的一般评论很可能是答案的一部分，并且可能进行了详细说明。