在我的Apache服务器（mod_deflate）中启用gzip压缩后，我发现最终用户的平均服务时间比未压缩的响应慢200毫秒。
这是出乎意料的，因此我将压缩指令修改为仅压缩文本/ HTML响应，启动wireshark并在压缩之前和之后查看网络转储。
以下是我对 GET 的观察，网络流量最小
Transactions on the wire: 46 Total time for 46 trans: 791ms i. TCP seq/ack: 14ms ii. 1st data segment: 693ms iii. Remaining: 83ms (27/28 data units transferred + tcp/ip handshakes)
Transactions on the wire: 10 Total time for 46 trans: 926ms i. TCP seq/ack: 14ms ii. 1st data segment: 746ms iii. Remaining: 165ms (5 out of 6 data units transfered)
在设置压缩之后，可以清楚地理解线路上的事务数量明显低于未压缩的事务数量。
但是，压缩数据单元从源到目标的传输时间要长得多。
看起来额外的压缩工作可以理解花费时间，但无法理解为什么每次发送的数据在压缩时显着变慢。
我对压缩过程的理解是：
1. GET Request is received by Apache 2. Apache identifies resource 3. Compress the resource 4. Respond with compressed response
通过这个方案，我会假设第3步是（响应的第一段之前的步骤需要更长的时间，因为我们 - 压缩+响应 - 但其余的我假设的块应该与未压缩的块平均相等，但它们不是。
任何人都可以告诉我原因......或建议更好的方法来分析这种情况。也有人有前后比较......我将不胜感激任何反馈/意见/问题
答案 0 :(得分：0)
我使用的测试不足以比较两种情况（我认为少于100种资源）。通过足够的测试 - 超过6000个网址，它表明在服务text / html中第一个字节的压缩响应时间快了200毫秒，而TTLB平均速度提高了25毫秒。
我没有加载测试我打算做的这个并更新这个答案。