Pull to refresh

GZip и nginx: влияние на производительность

Reading time 2 min
Views 35K
Добрый день. Недавно меня заинтересовал модуль ngx_http_gzip_static_module, и я решил погонять мой домашний сервер немного с разными настройками сжатия nginx, чтобы убедится, действительно ли современные процессоры настолько быстрые, что можно ставить сжатие в 9-тку и не париться. В качестве подопытного файла выступала слитая главная страница lenta.ru – 170кб. Во время тестирования обнаружилась интересная особенность, которая изменила мои взгляды на выбор количества процессов nginx.

Железо и софт


Тест выполнялся на Ubuntu Server 10.04, nginx 0.8.45, процессор – Opteron 165 (2 ядра, 1 метр кеш-памяти, 1.8Ghz).
Тесты запускались на самом сервере. Я их повторял и с другого компьютера через гигабитную сеть — результаты совпадают, отличие лишь там, где мы упираемся в пропускную способность сети.

Банальный gzip on;


Включаю gzip в nginx, начинаю гонять тесты, и случайно натыкаюсь на удивительную особенность: когда производительность упирается в скорость сжатия, nginx с 2-мя процессами работает практически в 2 раза быстрее чем с одним процессом, никакого сжатия в тредах…

Как видим, производительность очень даже ограничена производительностью процессора, и оснований думать что «процессоры нынче быстрые» нет, спокойно ставить сжатие на 9-тку не выйдет. При сжатии на 9-тку nginx выжирая только под сжатие все 2 ядра процессора отдает всего 4мб/сек сжатого контента, и не способен даже загрузить 100мбит-канал, не говоря уже о гигабите.

О выборе уровня сжатия


Если посмотреть на график размера сжатого файла (или на таблицу чуть ниже), видно что после 5-рки сжатие практически не растет, а вот скорость падает почти в 2 раза если сжимать на 9.
Степень сжатия Запросов в секунду Сжатый размер (оригинал 170кб)
1 370 51,7
2 350 48,9
3 294 45,7
4 242 44,2
5 181 41,3
6 134 39,7
7 115 39,5
8 103 39,4
9 102 39,4

Так что, ИМХО, ставить сжатие выше 5 не стоит.

Золотая пуля: ngx_http_gzip_static_module


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

Как видим, небо и земля. Также стоит отметить, что из-за дополнительной проверки на существование .gz файла немного падает производительность, если .gz файла нет.

Ну и бонус-трек: если включить и gzip_static и обычный gzip с уровнем сжатия например 1, то если предварительно сжатый файл будет найден – его и отдадут, а если такого файла нет, или например контент от апача приходит – то его сожмут на 1, максимально быстро.

Единственная проблема – это держать предварительно сжатые файлы в актуальном состоянии- тут уж кому как удобнее, или по крону, или скриптом деплоймента. Хотя конечно, было бы удобнее, если бы файлы генерировались, сохранялись и обновлялись nginx-ом автоматически… Эх, мечты, мечты…

Резюме

  • В nginx сжимать на 9 все нельзя, будет много процессора сжирать если трафик большой. Выше 5 ставить сжатие особого смысла нет, т.к. размер практически не уменьшается, а скорость падает сильно.
  • Количество процессов nginx при работе с gzip должно быть равно или больше количества ядер процессора.
    1 не достаточно, т.к. gzip сжатие тогда происходит только на 1 ядре.
  • gzip_static – крайне полезен, и дает гигантское преимущество при отдаче сжатой статики
Tags:
Hubs:
+77
Comments 43
Comments Comments 43

Articles