gzip对HTTP传输文件的速度影响是什么？

Question

我知道在通过网络发送文件之前解压缩文件可以节省带宽,对于可以缓存的静态文件,它对服务器端CPU使用率没有显着影响.

但客户呢？他们必须对任何发送的文件进行gunzip,这将占用CPU时间.另外,我担心在进行任何解析之前必须接收整个文件并进行喷枪压缩.

这让我很奇怪,因为我看到两种情况:

1) client has fast internet   -->   gzip is relevant
2) client has slow internet   -->   gzip prevents partial parsing

显然,准确的加速(或减慢？)将取决于正在传输的文件和客户端的确切情况.但是,我很好奇客户端的时间成本(或者我如何衡量成本)？

Answer 1

他们必须对任何发送的文件进行gunzip,这将占用CPU时间.

也许,但与加载页面时所发生的所有其他事情(解析,样式,渲染,脚本)相比,用于解压缩的CPU时间非常小.

我担心在进行任何解析之前必须接收并解压缩整个文件.

别担心,gzip是数据的"流",完整的文件不需要开始解压缩/解析.

具体来说,我想知道如何判断因为gzipping而损失了多少时间.

这是一篇有趣的文章,作者执行您所描述的测试类型.这些工具可供下载,以便您可以在自己的环境中执行相同的测试.

作者总结道:

我想极少数情况下你不应该使用gzip你的内容.如果您的典型页面少于100个字节,则gzipping会损害客户端和服务器的性能.但是没有网站 - 除了一些网络服务 - 提供典型大小为100字节或更少的页面.因此,没有理由提供未压缩的HTML.

Answer 2

同时(问题已经有点老了)大多数人都在使用TLS进行每个连接,所以关于性能的问题变得有点多余.但是看看这个仍然值得:

1)客户端有快速的互联网 - > gzip是相关的
2)客户端有慢的互联网 - > gzip阻止部分解析

情况恰恰相反.客户端的互联网连接(或到服务器的路由)越慢,您从gzip压缩(或一般压缩)中获得的优势就越大.

如果压缩/解压缩所花费的时间加上传输压缩数据所花费的时间少于立即传输未压缩数据所需的时间,则压缩很有用.

Gzip通常会将数据减少到原始大小的1/3到1/2之间(取决于它的大小),压缩大约为50MB/s(+/- 5).减压速度约为3倍.

100MBit以太网的吞吐量约为12.5MB/s,大多数人还没有100MBit的互联网接入(因为它通常堆叠在ATM之上,也比正常的以太网慢).此外,大多数人大多数时间都无法通过单次下载完全满足其高带宽互联网连接.

所以,实际上,对于一个普通的普通用户和一个不在你家的局域网中的服务器,而是"其他地方",假设你得到5MB/s(大约是我在这里的理论最大值的两倍,顺便说一下).

要传输50kB文件,您需要0.01秒.gzip压缩增加约0.001秒压缩,0.0003秒解压缩(让我们向上舍入并说总计0.002),但你只需传输16kB,这需要0.0032秒.

将它们加在一起,用gzip压缩传输速度大约是其两倍.

当然,最终(当普通用户将拥有200Mbit/s互联网,服务器具有100Gbit/s上行链路时),这个数字将会转变.