gzipされたApache応答パケット分析

Question

私の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番目のステップ（応答の最初のセグメントの前のステップは、圧縮+応答であるため長い時間がかかりますが、残りは想定されたチャンクのうち、圧縮されていないチャンクと平均して同じ時間かかるはずですが、そうではありません。

理由を教えてください...またはこのシナリオを分析するより良い方法を提案してください。また、誰も前と後の比較をしています...フィードバック/コメント/質問をいただければ幸いです

Answer 1

2つのシナリオを比較するのに不十分なテストを使用していました（100リソース未満だと思います）。十分なテスト-6000を超えるURLで、text / htmlを提供する場合、最初のバイトまでの圧縮応答時間が200ミリ秒速くなりましたが、TTLBは平均で25ミリ秒速くなりました。

これをロードテストしていないので、この回答を更新して更新する予定です。