تحليل حزمة استجابة أباتشي gzipped

Question

بعد تمكين ضغط gzip في خادم Apache الخاص بي (mod_deflate)، وجدت باستمرار أنه يتم تقديم الخدمة للمستخدم النهائي بمعدل 200 مللي ثانية أبطأ من الاستجابات غير المضغوطة.

كان هذا غير متوقع، لذا قمت بتعديل توجيه الضغط لضغط استجابات النص/HTML فقط، وتشغيل wireshark ونظرت في تفريغ الشبكة قبل الضغط وبعده.

وهذه ملاحظاتي على أ يحصل مع الحد الأدنى من حركة المرور في الشبكة

قبل الضغط

 
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

مع هذا المخطط، أفترض أن الخطوة الثالثة هي (الخطوة قبل الجزء الأول من الاستجابة ستستغرق وقتًا أطول لأننا -- الضغط + الاستجابة - ولكن بقية القطع التي افترضتها يجب أن تستغرق في المتوسط ​​وقتًا متساويًا مثل القطع غير المضغوطة ولكنها ليست كذلك.

يمكن لأحد أن يقول لي لماذا...أو اقتراح طريقة أفضل لتحليل هذا السيناريو.ومن لديه مقارنة قبل وبعد..وسأكون ممتنا لأي ردود فعل / تعليقات / أسئلة

Answer 1

كنت أستخدم اختبارًا غير كافٍ لمقارنة السيناريوهين (أعتقد أن أقل من 100 مورد).من خلال الاختبارات الكافية - أكثر من 6000 عنوان URL، أظهرت أن وقت الاستجابة المضغوط للبايت الأول كان أسرع بمقدار 200 مللي ثانية في تقديم النص/html، بينما كان TTLB أسرع بمقدار 25 مللي ثانية في المتوسط.

لم أقم بتحميل اختبار هذا الذي أخطط للقيام به وتحديث هذه الإجابة.