2. nginx – модульность
• Без модулей – плохо
• Модульность:
– удобно развивать основной функционал
– легко решать специфические задачи
3. Модули бывают разные
• nginx – 3-й в мире, 2-й в России*
• много разного кода
Совет: изучайте внимательно то, что собираетесь
использовать.
* http://openstat.ru/counter/trends
4. Модули
• auth request http://mdounin.ru/
• bytes filter Все модули – простые.
• compose
• gunzip
• ip tos
• upstream keepalive
5. auth request
Авторизация через подзапрос.
Если подзапрос вернул 200 – доступ
разрешён, иначе – нет.
Что-то вроде fastcgi authorizers, ЕВПОЧЯ.
8. bytes filter
Возврат отдельных диапозонов данных из ответа. Аналог
range фильтра из стандартной поставки, но:
• Диапазоны не в заголовках, а непосредственно в
аргументах запроса.
• Обычный ответ с кодом 200.
• Работает с любым потоком данных, в т.ч. от proxy.
11. compose filter
Возвращает ответ от нескольких подзапросов, но позволяет
указать Content-Length результата (и разрешает Range-запросы).
Зачем? Вместе с bytes filter позволяет художественно вставлять в
медиа-файлы другие медиа-файлы, сохраняя возможность
докачки.
Требует патчей:
http://mdounin.ru/hg/nginx-compose/
15. gunzip
location / {
gunzip on;
gzip_static always;
}
Экономим диск и память под файловый кеш.
Нужен патч для gzip_static always.
16. gunzip
location / {
gunzip on;
memcached_gzip_flag 2;
memcached_pass ...;
}
Экономим память в memcached. Нужен патч для
memcached_gzip_flag.
17. gunzip
Бонус: патч для perl-модуля, чтобы разжимались сжатые ответы из
embedded perl.
Все три описанных патча периодически проскакивают в рассылке
nginx-devel@nginx.org. Последний раз они замечены тут:
http://nginx.org/pipermail/nginx-devel/2011-February/000734.html
http://nginx.org/pipermail/nginx-devel/2011-February/000735.html
http://nginx.org/pipermail/nginx-devel/2011-February/000736.html
18. ip tos
Позволяет ставить IP TOS байт для ответов.
Потом можно лимитировать /
приоритизировать трафик вашим любымым
firewall'ом.
19. ip tos
ip_tos 0x00;
location /video/ {
ip_tos 0x10;
}
22. Почему нет keepalive'а с бекендами?
• Типичное время генерации ответа бекендом - 20 ms (будем
верить в хорошее).
• Хорошее RTT до пользователя – 30 ms (ADSL). В среднем > 100
ms.
• На таком фоне установление соединения с бекендом обычно
незаметно.
Вывод: нужно в специфических случаях.
23. Специфические случаи
1. Плохие бекенды, с высокой стоимостью
установления соединения.
2. "Далёкие" бекенды, с большим RTT до них.
3. Хорошие бекенды, отдающие ответ за < 1ms и
немного пакетов. Особенно если при этом
реальный ответ собирается из большого
количества подзапросов.
24. upstream keepalive
В настоящий момент upstream keepalive умеет:
1. memcached
2. fastcgi (+ требуются патчи)
3. proxy unbuffered (+ Content-Length от бекенда)
Мы работаем над улучшением ситуации.