Nginx *

 

Как было написано сегодня в рассылке, ветка 0.7 стала стабильной. Процитирую слова Игоря о нововведениях:

*) кэширование проксированных и FastCGI-серверов;
*) директива try_files;
*) поддержка выделений в регулярных выражениях в директивах location и server_name и ссылок на эти выделения во всех директивах, поддерживающих переменные, например, в директиве alias;
*) два фильтра — XSLT и преобразования изображений;
*) предварительная поддержка IPv6;
*) nginx/Windows.

Дополнил цитату ссылками на соответствующую документацию.
Скачать nginx можно на странице http://sysoev.ru/nginx/download.html.

Выпустил обновление для своего патча, в котором собраны воедино все мои патчи

Статья написана по материалам моего доклада на CodeCamp 2009.

Для многих из нас настает тот долгожданный день, когда аудитория сайта начинает стремительно расти. Каждое утро мы, затая дыхание, смотрим на графики google analitycs и расплываемся в улыбке, когда взят рубеж в очередную тысячу посетителей в день. Как правило, рост посещаемости не совпадает с ростом технической базы и сайт начинает тормозить. Тут в игру вступает сисадмин...

У любого проекта всегда есть что оптимизировать: можно почитать советы по оптимизации на webo.in, установить eaccelerator, memcache, проиндексировать поисковые поля в базе данных. Я предполагаю, что все это уже проделано, а сайт по прежнему тормозит.

Пришло время оптимизировать nginx...

Почти год назад на RIT 2008 Игорем Сысоевым была анонсирована поддержка кеширования в будущих версиях nginx. И вот сегодня вышла новая бета nginx 0.7.44, в которой появилось это долгожданное кеширование

Этот функционал оценят в первую очередь разработчики высоконагруженных систем, для которых операция установления сетевого соединения с backend «дороже» обычной дисковой операции (с точки зрения затраты ресурсов)

На RIT 2008 автор отмечал, что большим преимуществом nginx перед демоном squid, который тоже можно использовать как reverse proxy, является отсутствие стартового торможения, когда squid начинает сканировать директорию с кешем, что в народе называется «давать сквида».

Хочется отметить, что некого подобия кеширования можно было добиться с помощью использования директив proxy_store + try_files, но управлять таким кешем было достаточно сложно и затратно.

Очень интересно было бы услышать отзывы от пользовалелей замонтировавших кеш на SSD-диск.

Только что вышла версия 0.7.44 в которой обещается предварительная поддержка кеширования в ngx_http_proxy_module.

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

Не переставая петь хвалебные песни nginx`у, представлю публики моё решение для очень простого отображения аватаров на проектах.
Задача простая — вывести аватар пользователя, если он у него есть и вывести дефолтовый, если нет аватара у пользователя.
Допустим, все аватары физически у нас хранятся в /img/avatar/, без разницы с какими именами. Решение «в лоб» будет тоже простым — писать в базу, загрузил пользователь аватар или нет. Но это потребует каждый раз обращаться в базу. Конечно, можно юзать мемкеш и прочее, но есть более элегантный выход из ситуации, на мой взгляд ­— переложить эту задачу на плечи nginx`а. И nginx очень легко с этим справляется:

error_page 404 =200 /img/avatar/default.gif;


Игорь Сысоев в рассылке nginx-ru пишет:

На днях интересовался, как делается перенаправление запросов в Drupal и прочие.

Хочу представить публике небольшой патч, который подменяет аллокатор.

Кратко: после его применения потребления памяти сократилось почти в два раза, а idle вырос на 15%.

Update: учел исправления, добавил jemalloc и опции для выбора с чем собирать. Краткое описание и патч.

Update: провел микро тестирование

Однажды холодной сибирской зимой начальство решило согреть нашу команду горячей начальственной любовью и передало в наши руки еще один проект. С первого же взгляда обнаружилось несколько серьёзных проблем:

• Это было написано на PHP;
• Это было написано на таком PHP, что **** **** ***;
• Захардкожено было всё, и ни о какой расширяемости или настраиваемости речи не шло. А ведь нагрузка росла не по дням.

В общем, как настоящие русские парни, мы решили все сломать к хренам собачьим и построить заново, сделав красиво. Почесав репу решили, что apache+modperl — это для старпёров и не интересно, а fastcgi — путь слабых духом, поэтому все будем делать на nginx + его вечноэкспериментальный встроенный перл.

Позже я почувствовал себя на густозасеянном разного размера глаблями поле…

Хочу представить вам небольшой патч, который реализует возможность использовать такие конструкции для настройки:

location /response {
    response "<root><pid>$pid</pid></root>";
    response_type "text/xml";
}

Модуль для nginx, с помощью которого достаточно просто мониторить прогресс загрузки файлов на сервер. Ранее были подобные решения, через модули к php, ruby, через стороние скрипты, flash объекты итп. Автор предлагает универсальное решение на уровне web сервера. Подробную информацию и инструкции вы можете найти на wiki.codemongers.com (кстати, один из лучших проектов, посвященных nginx`у). Тут я хотел обратить внимание на другое.
Использовал модуль совместно с nginx upload module, работает на ура. Однако файлы, что я заливаю, достаточно большие (поддерживаю файлообменник), пытался запихнуть в директиву upload_progress размер обрабатываемых файлов — 1g, при релоаде nginx`а получил варнинг, мол непонятный размер вы поставили. Странно, т.к. в client_max_body_size у меня стоит 1g и нормально себя чувствует. Глянул исходники nginx`а и модуля, выяснелось, что модуль обрабатывает директиву upload_progress функцией ngx_parse_size, тогда как сам nginx обрабатывает ту же client_max_body_size соседней функцией ngx_parse_offset, функции абсолютно идентичны (на мой взгляд), разве что первая не понимает размерность «g», а вторая понимает =) Для того, чтобы модуль нормально обрабатывал размерность в директиве upload_progress, надо в исходнике модуля (ngx_http_uploadprogress_module.c) в строчке 1151 исправить ngx_parse_size на ngx_parse_offset.
В общем это не критично, т.к. директива нормально обрабатывает значение 1024m, но как-то нелепо выглядит подобная запись =)))
А вообще модуль очень понравился, очень удобное решение, не зависящее от бэк-енда.

update: Внимание, совершил глупую ошибку. Стыдно. Деректива upload_progress задает не максимальный размер загружаемых файлов для указанной зоны, как я думал, а размер оперативной памяти, выделяемой для обсчета одной загрузки в эту зону. Значение для этой дерективы — 1,2m, максимум 10-20m. Задавая 1g вы будете тратить гигабайт оперативки на каждую загрузку. Стыдно, ошибку не повторяйте.
p.s. тем не менее баг найден, автору сообщил, он обещал исправить.

Странно, что подобного блога еще нет на Хабре. Имею честь начать.
Я не претендую на гуру nginx, но использую его уже значительное время и имею представление, что это.
Всем привет, вливайтесь.