【发布时间】：2009-08-03 20:25:32
【问题描述】：
在我的 Apache 服务器 (mod_deflate) 中启用 gzip 压缩后，我始终发现最终用户的服务平均比未压缩响应慢 200 毫秒。
这是出乎意料的，因此我将压缩指令修改为仅压缩文本/HTML 响应，启动了 wireshark 并查看了压缩前后的网络转储。
这是我对网络中流量最小的 GET 的观察
压缩前
在线交易：46 46个trans的总时间：791ms 一世。 TCP seq/ack: 14ms ii.第一个数据段：693ms 三。剩余时间：83ms（27/28 个数据单元传输 + tcp/ip 握手）压缩后
在线交易：10 46个trans的总时间：926ms 一世。 TCP seq/ack: 14ms ii.第一个数据段：746ms 三。剩余时间：165 毫秒（传输 6 个数据单元中的 5 个）设置压缩后，网络上的事务数量明显低于未压缩时，这一点很清楚且可以理解。
但是，压缩数据单元从源传输到目标需要更长的时间。
似乎可以理解，额外的压缩工作需要时间，但无法理解为什么压缩时发送的每个数据都明显变慢。
我对压缩过程的理解是：
1. Apache收到GET请求 2. Apache识别资源 3.压缩资源 4. 以压缩响应响应使用这个方案，我假设第三步是（响应的第一段之前的步骤将花费更长的时间，因为我们正在 -- 压缩 + 响应 -- 但其余的我假设的块的平均时间应该与未压缩的块相同，但事实并非如此。
谁能告诉我为什么……或者建议一种更好的方法来分析这种情况。还有人有之前和之后的比较...我将不胜感激任何反馈/cmets/问题
【问题讨论】：
-
这确实属于Serverfault。
-
好的，我会跟进serverfault。谢谢
标签： apache compression gzip deflate mod-deflate