Что такое минимальный размер объекта для преимуществ производительности gzip?

Я работаю над улучшением времени отображения страницы, и одним из методов является gzip-контент с веб-сервера.

Google рекомендует :

  

Обратите внимание, что gzipping полезен только для больших ресурсов. Из-за накладных расходов и латентности сжатия и декомпрессии, вы должны только gzip файлы выше определенного порога размера; мы рекомендуем минимальный диапазон между 150 и 1000 байтами. Файлы Gzipping ниже 150 байт могут сделать их более крупными.

Мы обслуживаем наш контент через Akamai , используя свою сеть для прокси и CDN. Что они сказали мне:

  

В ответ на вопрос о минимальном размере Akamai сжимает запрошенный объект при отправке его конечному пользователю: минимальный размер составляет 860 байт.

Мой ответ:

  

В чем причина (почему), почему минимальный размер Akamai составляет 860 байт? И почему, например, это не так для файлов Akamai служит для Facebook? ( см. ниже ) Google рекомендует gzip более агрессивно. И это кажется уместным на нашем сайте, где наиболее частые удары, безусловно, являются вызовами AJAX, которые составляют <860 байт.  Facebook заголовки скриншотов оспаривают заявление Akamai

Ответ Акамай:

  

Причины 860 байт минимальный размер для сжатия двоякий: (1) Накладные расходы на сжатие объекта под 860 байт перевешивают производительность. (2) Объекты под 860 байтами могут передаваться через один пакет в любом случае, поэтому нет необходимости их сжимать.

Итак, я здесь для проверки некоторых фактов. Является ли ограничение в размере 860 байтов из-за размера пакета в конце этого рассуждения? Почему сайты с высоким трафиком ограничивают это ограничение до 150 байтов ... просто для экономии затрат на пропускную способность (поскольку CDNs основывают свои расходы на пропускную способность, выгруженную из источника), или есть ли выигрыш в производительности при этом?


Обновление 7/9/12: Я спросил Steve Souders , если есть усиление производительности в gzipping ответах, которые уже меньше, чем пакет, и что рекомендуемый минимальный размер объекта для производительности gzip выгоды, и это его ответ:

  

Спасибо за ваш адрес электронной почты. Размер находится где-то между 1-5K. Apache имеет   по умолчанию, но я забыл, что это такое - это было бы хорошим руководством.

Мы выполняем сжатие на устройстве F5, поэтому мы собираемся снизить его до ~ 350 байт, так как существует достаточное количество вызовов AJAX между этим и 1K. AJAX-вызовы, которые меньше 350 байтов на нашем веб-сайте, упали примерно на 70 байт ... меньше рекомендаций Google ... так что, похоже, он возвращается, чтобы: знать ваш сайт и настраивать на основе вашего кода .

Я вернусь к этому сообщению после того, как обновление F5 будет запущено в Production некоторое время. Я думаю, что будет небольшое преимущество в производительности, но мы немного снизим расходы на Akamai, так как они меньше обслуживают.

29 голосов | спросил utt73 5 J000000Thursday12 2012, 21:00:30

1 ответ


2

Вы говорите о преимуществах затрат на пропускную способность, но затем также сравниваете производительность загрузки страницы в браузере. Это две разные вещи.

В любое время, когда вы загружаете запрос, что-то должно действительно выполнить сжатие (в вашем случае, F5), а клиент (или технически прокси) должен обрабатывать декомпрессию. Это может добавить к вашему запросу больше латентности, в зависимости от того, насколько возможно аппаратное обеспечение на обоих концах.

«Минимальный размер для gzip» основан на времени, необходимом для сжатия /распаковки данных, которые не являются полезными с точки зрения просмотра веб-браузера. Если вы просто говорите об экономии пропускной способности, то идите вперёд и установите минимальный минимум, как вам хотелось бы, но сделайте это, зная, что вы не можете давать конечным пользователям прирост производительности.

ответил Nicholas Head 12 J000000Thursday12 2012, 21:54:59

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132