Добрый день. Недавно меня заинтересовал модуль 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 в nginx, начинаю гонять тесты, и случайно натыкаюсь на удивительную особенность: когда производительность упирается в скорость сжатия, nginx с 2-мя процессами работает практически в 2 раза быстрее чем с одним процессом, никакого сжатия в тредах…
Как видим, производительность очень даже ограничена производительностью процессора, и оснований думать что «процессоры нынче быстрые» нет, спокойно ставить сжатие на 9-тку не выйдет. При сжатии на 9-тку nginx выжирая только под сжатие все 2 ядра процессора отдает всего 4мб/сек сжатого контента, и не способен даже загрузить 100мбит-канал, не говоря уже о гигабите.
Если посмотреть на график размера сжатого файла (или на таблицу чуть ниже), видно что после 5-рки сжатие практически не растет, а вот скорость падает почти в 2 раза если сжимать на 9.
Так что, ИМХО, ставить сжатие выше 5 не стоит.
Этот модуль позволяет избавиться от сжатия снова и снова одних и тех же файлов. Мы просто максимально сжимаем их заранее, и кладем в том же каталоге с расширением .gz, и если они есть – то будет отдаваться сжатый файл и очень быстро:
Как видим, небо и земля. Также стоит отметить, что из-за дополнительной проверки на существование .gz файла немного падает производительность, если .gz файла нет.
Ну и бонус-трек: если включить и gzip_static и обычный gzip с уровнем сжатия например 1, то если предварительно сжатый файл будет найден – его и отдадут, а если такого файла нет, или например контент от апача приходит – то его сожмут на 1, максимально быстро.
Единственная проблема – это держать предварительно сжатые файлы в актуальном состоянии- тут уж кому как удобнее, или по крону, или скриптом деплоймента. Хотя конечно, было бы удобнее, если бы файлы генерировались, сохранялись и обновлялись 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 – крайне полезен, и дает гигантское преимущество при отдаче сжатой статики