Почему gzip_static лучше gzip?

В одном из комментариев у меня спросили, почему не использовать обычный gzip вместо gzip_static. Давайте попробую объяснить, за что я люблю именно gzip_static, и почему его использование - это очень хорошо.
По сути, у серверов есть четыре основных ресурса: память, процессор, жесткий диск и полоса пропускания канала.

Для тестирования возьмем синтетический достаточно большой файл в 301.26 КБайт. Сделаем мы его, объединив все файлы из каталога JQuery в WordPress. Экономией памяти при отдаче небольшого файла можно пренебречь: память все равно будет мгновенно освобождена. Лишним потреблением места на диске – думаю, тоже. Лог-файлы куда больше места занимают :). А вот на расходование ресурсов процесора и экономию канала – посмотрим ниже.

Приступим! Нам важно знать, что у gzip есть несколько степеней сжатия (от 1 до 9, чем эта цифра больше, тем лучше результат). Попробуем сжать наш файл со всеми возможными степенями сжатия:

for i in `seq 1 9`; do cat ji.js | gzip -$i > ji.js.$i.gz; done
ls -l ji.js*
-rw-r--r-- 1 baron baron 308497 Jul 12 22:52 ji.js
-rw-r--r-- 1 baron baron 109960 Jul 12 22:55 ji.js.1.gz
-rw-r--r-- 1 baron baron 106027 Jul 12 22:55 ji.js.2.gz
-rw-r--r-- 1 baron baron 102998 Jul 12 22:55 ji.js.3.gz
-rw-r--r-- 1 baron baron  96356 Jul 12 22:55 ji.js.4.gz
-rw-r--r-- 1 baron baron  93214 Jul 12 22:55 ji.js.5.gz
-rw-r--r-- 1 baron baron  92371 Jul 12 22:55 ji.js.6.gz
-rw-r--r-- 1 baron baron  92194 Jul 12 22:55 ji.js.7.gz
-rw-r--r-- 1 baron baron  92109 Jul 12 22:55 ji.js.8.gz
-rw-r--r-- 1 baron baron  92109 Jul 12 22:55 ji.js.9.gz

Из результатов видно, что для достижения хорошего результата достаточно использовать сжатие со степенью 4 или 5. Как правило, при включении динамического сжатия, используется один из этих коэффициентов. Очевидно, использование сжатия даже 1 степени, значительно экономит ресурсы канала. Но сжатие 9 степени экономит ресурсы канала эффективнее на несколько процентов. В данном случае, сжатый файл занимает от 35.64% до 29.85% от оригинала. Но посмотрим, какой ценой это достигается:

Сожмем файл 100 раз, для оценки затрат процессора. Для этого создадим скрипт такого содержания:

for i in `seq 1 100`; do cat ji.js | gzip -$1 >/dev/null; done

Выполним скрипт с каждым параметром сжатия от 1 до 9:

for i in `seq 1 9`; do time sh ji.sh $i 2>&1 ; done
sh ji.sh $i 2>&1  0.00s user 0.02s system 2% cpu 0.912 total
sh ji.sh $i 2>&1  0.01s user 0.02s system 3% cpu 0.983 total
sh ji.sh $i 2>&1  0.87s user 0.15s system 90% cpu 1.130 total
sh ji.sh $i 2>&1  0.92s user 0.10s system 82% cpu 1.232 total
sh ji.sh $i 2>&1  0.91s user 0.11s system 64% cpu 1.576 total
sh ji.sh $i 2>&1  1.01s user 0.08s system 55% cpu 1.969 total
sh ji.sh $i 2>&1  1.93s user 0.09s system 91% cpu 2.202 total
sh ji.sh $i 2>&1  1.94s user 0.08s system 75% cpu 2.669 total
sh ji.sh $i 2>&1  1.99s user 0.03s system 73% cpu 2.762 total

Опять-таки, наиболее приемлемые с точки зрения затрат процессорного времени результаты показывает сжатие со степенью 4 или 5. Такое сжатие работает в 2 раза быстрее, чем сжатие со степенью сжатия 8.

Составим небольшую таблицу.

Таким образом, статическое сжатие по эффективности равно динамическому сжатию 9. При этом ресурсы процессора не расходуются. Если же мы выбираем “стандартное” сжатие 4, то мы отдаем на 4.6% больше трафика по сравнению со статическим сжатием. Также, на 100 отдач расходуется примерно секунда процессорного времени. Вообще, “минусом” от включения gzip_static часто можно пренебречь: необходимость держать в дисковом кэше лишнюю сотню килобайт на сайт – не проблема. А еще хардлинки есть… :)

4,5% – много это или мало? Решать нужно индивидуально. Очевидно, что если сайт находится в разработке, т.е. стили и скрипты меняются по несколько раз на дню, использовать статическое сжатие – не лучшая возможность. Ведь каждый раз необходимо обновить заранее подготовленную копию файла.

Однако, бывает и наоборот – когда сайт имеет многотысячную (а то и многомиллионную аудиторию), работает на кластере серверов и все равно не справляется с задачей (например, lenta.ru неоднократно вынуждена была включать “облегченную версию”, без картинок, использующихся для оформления сайта). И в этом случае экономия даже жалких 4% канала – огромна.

Однако, администрировать новостные сайты, подобные Ленте, доводится не всем. Впрочем, вот еще другой пример. У моего знакомого, занимавшегося сателлитостроением, на одном сервере “крутилось” около 3000 сателлитов – с разной посещаемостью, часть правда совсем убитые. На этой отметке его сервер перестал справляться с нагрузкой, знакомый интересовался, смогу ли я ему настроить новый сервер. Впрочем, разрешили ситуацию к обоюдному удовлетворению: радикально снизили загрузку существующего сервера. Там правда проблема была не в процессоре, а в чрезмерной прожорливости Вордпресса.

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