Исследование степени gzip-сжатия и загрузки процессора

[@Isis]

Я честно не понимаю почему gzip считается лучшим сжатием....
Ведь при включенном gzip при переходе "Назад" в браузере страница грузится зпново, а без gzip берется из кеша...
За статью спасибо

[@sergey_novikov]

Хм, а почему с gzip страница грузится заново? И какой броузер так делает?

[@ssve]

Какая взаимосвязь между gzip и кешем?

[@dmx]

Зависимость такая, что, например, IIS отключает по умолчанию кеширование при сжатии файлов. Это связанно с тем, что файл может закешироваться на каком-нить прокси и, если клиент не поддерживает gzip, то он никак не сможет получить нормальную несжатую версию файла. В связи с этим и не советуют включать кеширование для сжатых файлов.

When you enable HTTP compression, compressed files are given a default expiration date of Jan. 1, 1997. This expiration date prevents proxy servers from serving cached copies of compressed files to browsers that are not compression-enabled.

Хотя, думаю, можно просто обойтись Cache Control: Private.

[@sunnybear]

я тоже поддерживаю последний способ. Хотя проблем, которые описываются таким стечением обстоятельств, реально, очень мало (<0,1%).

[@mivlad]

Прокси разве не должен смотреть на accept-encoding?

[@dmx]

Мне кажется ему пофиг :)

[@dmx]

1) далеко не все юзеры пользуются кнопкой назад
2) не на всех сайтах есть такая необходимость
3) тот маленький процент страниц, которые будут запрошены в результате нажатия кнопки "назад" не сэкономят траффик так, как это делает компрессия. На некоторых сайтах компрессия экономит траффик в 5 раз, бывает и больше. Вот грубо если посчитать, одна такая зазипованная странница оправдает 5 раз нажатие кнопки назад :)

[@easterism]

По первому пункту. Откуда информация?

[@dmx]

Сразу ссылку не приведу, но слышал не из одного источника. Вот последний - это Бобук в интервью с разработчиком IE. Он там цифру называл на основе яндексовских наблюдений. Понятно, что не последняя инстанция, но тенденция, я думаю, есть к этому.

[@Wenye]

Сильно зависит от того, как сайт построен. Я действительно на яндексе не пользуюсь кнопкой назад — там это просто незачем.

[@dmx]

Согласен с вами. Я не утверждаю, что мои предположения — 100% точные расчеты.

[@Rational_Yurij]

Рисунок 1. Издержки на gzip от степени сжатия
А какого размера тестовая страничка сжимается?

[@sunnybear]

около 60 Кб. В первом исследовании — от 500 до 128000 байтов

[@alrond]

Идеальный рецепт :)
1) для css и js использовать модуль http_gzip_static_module в nginx. для браузеров, поддерживающих сжатие отдает уже заранее приготовленный gz (степень сжатия = 9)
2) для динамики использовать динамическое сжатие в nginx-е со степенью сжатия = 1

[@AmdY]

Я думаю единица маловато, ведь затраченное время и процессор вернутся из-за того, что нужно передать меньше данных.

[@isysoev]

Судя по графикам, если увеличить степень сжатия с 1 до 6, то ответ будет меньше всего на 4%, зато время создания/загрузка процессора увеличится на 100%, то есть, в 2 раза.

[@AmdY]

я сжимал css, js, html на 6-ке сжатие
улучшилось на 22.3, 12.6, 12.6
для другого проекта 9.8, 18.8, 12.7

[@isysoev]

А как считалось разница - в процентах от исходного файла ? Можно привести примеры ? Например, берём prototype-1.6.0.2.js - 126127 байт, gzip -1 - 36182, gzip -6 - 29206. Получаем 71.3% и 76.8%.

[@AmdY]

if (! $files = scandir('./files/')) die('not exist \'./files/\'');
$times = array();
foreach($files AS $v) {
if ($v == '.' || $v == '..') continue;
$content = file_get_contents('./files/'.$v);
for($i=1;$i





-

[@AmdY]

Упс, извиняюсь, хотел весь скриптик всунуть, чтобы другие могли потестить.
сравниваю примерно так: от размера файла сжатого с степенью 1 отнимаю размер со сжатием 6 и результат делю на размер со степенью 1.
ajax.js 1 - 2803 2 - 2.7 3 - 4 4 - 7.7 5 - 9.6 6 - 9.8 7 - 9.8 8 - 9.8 9 - 9.8
bm.my.htm 1 - 4845 2 - 5 3 - 6.7 4 - 10.6 5 - 16.4 6 - 18.8 7 - 19.2 8 - 20.1 9 - 20.1
style.css 1 - 707 2 - 1.8 3 - 4 4 - 9.3 5 - 11.7 6 - 12.7 7 - 12.9 8 - 12.9 9 - 12.9

[@isysoev]

Я это и предполагал. Считать разницу имеет смысл от полного размера, а не от сжатого со степенью 1.

[@AmdY]

Я думаю, сравнивая два метода, логичнее было бы сравнивать их результаты. В данном случае я вижу, что сжатие 6 поможет сократить трафик на 10-15 процентов, оборотно стороной является значительная загрузка процессора по сравнению с степенью 1.

[@sunnybear]

в большинстве случаев, загрузка процессора не настолько существенна

[@kashey]

В большинсве случаев на загрузку гзипом можно начхать :)
Всеравно страница генериться как минимум раз так в 5-6-7 дольше.
Средне по рунету - начиная от 100 раз дольше( если брать время работы гзипа 14мсек)

[@sunnybear]

:) там ошибка в графике была. Время работы 10000 итерация было в секундах, соответственно, время на сжатие 60Кб на сервере было порядка 1-2мс, что совсем мало :)

[@kashey]

Ну тоесть на это время еще малек(раз так в десять) "побарабаней" :)

[@seljedka]

Игорь, небольшой оффтоп: когда планируется релиз версии nginx с кешированием?