Nginx *

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

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

Для этой цели, мы можем воспользоваться nginx-овым SSI. Никаких изменений в конфиг nginx вносить не придётся, а сама страничка может выглядеть примерно так:

<!--# config timefmt="%d%m%Y" -->
<!-- мы только что установили, что переменная $date_local дожна иметь вид ддммгггг-->
<!--# if expr="$date_local = 01012010" -->
<!--# include virtual="/path/to/new_year_congratulations/" stub="Oops!" -->
<!--# else -->
<!--# include virtual="/path/to/usual/version/of/block/" stub="Oops2!" -->
<!--# endif-->
<!-- если переменные $date_local или $date_gmt используются где-то ещё, неплохо бы вернуть обратно формат по умолчанию, если он нужен -->


И теперь, ровно в полночь, 1 января 2010 года, ваши пользователи увидят поздравление с новым годом на месте какого-то обычного блока. Причём, вы в это время можете спокойно спать (ну или, пьянствовать с друзьями). :) Более того, ровно в полночь, второго января, поздравление исчезнет, без малейшего вашего участия.

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

Естественно, у него есть и недостатки:
— ваш if будет исполняться при каждой отдаче страницы — это может быть критично на серверах с очень медленным процессором, или на VPS;
— некоторые промежутки времени таким образом определить всё-же не получится, или это потребует не одного оператора «if»;
— что-то ещё… :)

Но, в целом — неплохое, удобное, а главное, быстрое решение.

В последних версиях nginx (начиная с 0.8.11) появилась поддержка асинхронного файлового ввода-вывода. Потенциально, эта фича способна устранить одно из узких мест веб-сервера — полную блокировку процесса при файловом IO.

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

Раньше, эта проблема решалась увеличением количества процессов-воркеров. Теперь есть альтернативное решение. :) Однако, перед тем, как включать файловый AIO, стоит учесть ряд нюансов.

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

Во-вторых, файловый AIO работает только на FreeBSD 4.3 и выше, либо в Linux, с версии ядра 2.6.22 и выше.

В-третьих, AIO во FreeBSD имеет смысл включать только в версиях FreeBSD-6.4 STABLE, FreeBSD 7, или новее. В более ранних версиях, при включении AIO, сетевая подсистема начинает использовать Giant Lock, что означает невозможность одновременного выполнения какого-то другого системного вызова. Другими словами, почти никаких выгод от асинхронности мы не получим.

Ну и наконец, при использовании AIO под Linux надо также включать directio. Также, если я всё понял правильно, в линукс пока невозможно использовать AIO для подгрузки данных для sendfile, поскольку включение directio отключит использование sendfile автоматически.

Если вы по-прежнему считаете, что оно вам нужно, AIO включается очень просто. Для Linux, фрагмент конфига будет выглядеть примерно так:

aio on; # включаем AIO
directio 512; # включаем O_DIRECT для файлов, размером 512 байт или больше
output_buffers 128 512k; # зная размер и примерное количество одновременно отдаваемых файлов, можно подобрать более подходящие значения


Ссылки:
Описание AIO в документации на Nginx
Changelog

Раз уж зашел разговор о редких и полезных модулях для nginx — я расскажу вам об онлайн упаковщике ZIP файлов для nginx. Он позволяет на лету формировать ZIP архив из заданного списка файлов с возможностью многопоточной скачки и докачки файла, но без сжатия.

Решил осуществить давнюю мечту, и написать про некоторые модули nginx, которые используются довольно редко. Сегодня речь пойдёт про random_index_module.

Тема правильной настройки nginx очень велика, и, боюсь, в рамки одной статьи на хабре никак не помещается. В этом тексте я постарался рассказать про общую структуру конфига, более интересные мелочи и частности, возможно, будут позже. :)

Неплохой начальной точкой для настройки nginx является конфиг, который идёт в комплекте с дистрибутивом, но очень многие возможности этого сервера в нём даже не упоминаются. Значительно более подробный пример есть на сайте Игоря Сысоева: sysoev.ru/nginx/docs/example.html. Однако, давайте лучше попробуем собрать с нуля свой конфиг, с бриджем и поэтессами. :)

Я использую nginx как фронт сервер для своего проекта. Сам проект пишется на Java в IntelliJ IDEA. Захотелось редактировать конфиги nginx и запускать nginx сразу в IDEA. Сел и написал плагин.

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

Не секрет, что пользователи любят, когда контент на сайте обновляется чаще, чем раз в год. Эту любовь пользователей к динамическим страничкам разделяют и поисковики. Google, например, умеет определять наличие обновляющихся блоков на страничке и добавляет ей немного кармы (читай, PR).

Однако динамический контент довольно плохо сочетается с большими нагрузками. Для веб-сервера, отдача статической странички — намного более простая задача, чем запуск кода, который сгенерит эту страничку динамически. В некоторых случаях может выручить прегенерация всех возможных вариантов странички, но это не спасёт, если их слишком много, или страница обновляется слишком часто.

Давно я тут не писал про развитие своего fork nginx.

С момента моего последнего рассказа тут, появилось много интересной функциональности.

• $mstimestamp
• альтернативный статус
• $loadavg_… и ‘<'/'>‘ в if
• ssi изменение поведение include
• статус по url
• случайное число в ответе

Предвидя вопросы. Да, я этим пользуюсь. Этим пользуется еще несколько человек. Нет, это скорее всего никогда не войдет в оригинальный 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 + его вечноэкспериментальный встроенный перл.

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