После включения сжатия gzip на моем сервере Apache (mod_deflate) я обнаружил, что конечный пользователь обслуживается в среднем на 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-й шаг - это (шаг до самого первого сегмента ответа займет больше времени, так как мы - сжимаем + отвечаем - но остальные куски, которые я предположил, должны занимать в среднем то же время, что и несжатые куски, но это не так.
Может кто-нибудь сказать мне, почему ... или предложить лучший способ проанализировать этот сценарий. Также у кого-нибудь есть до и после сравнения ... Буду признателен за любые отзывы / комментарии / вопросы