Блог вебмастера

В web-сервер и reverse-proxy nginx встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Этой статьей я попробую немного улучшить ситуацию.



В этой статье: а) подводные камни при полностраничном кэшировании; б) кэширование с ротацией; в) создание динамического «окна» в закэшированной странице.



Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*



Если выбирать, кэшировать ли страницу на стороне PHP или на стороне nginx, я выбираю nginx. Во-первых, это позволяет отдавать 5-10 тыс. запросов в секунду без каких-либо сложностей и без умных разговоров о «высокой нагрузке». Во-вторых, nginx самостоятельно следит за размером кэша и чистит его как при устаревании, так и при вытеснении нечасто используемых данных.

Кэширование всей страницы целиком

Если на вашем сайте главная страница хоть и генерируется динамически, но меняется достаточно редко, можно сильно снизить нагрузку на сервер, закэшировав ее в nginx. При высокой посещаемости даже кэширование на короткий срок (5 минут и меньше) уже дает огромный прирост в производительности, ведь кэш работает очень быстро. Даже закэшировав страницу всего на 30 секунд, вы все равно добьетесь значительной разгрузки сервера, сохранив при этом динамичность обновления данных (во многих случаях обновления раз в 30 секунд вполне достаточно).

Удаленный пользователь может обойти некоторые ограничения безопасности. …

Доброе утро, Хабр!



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

В последнее время на Хабре стала популярной тема реализации высокопроизводительных приложений. Решили тоже немножко поэкспериментировать в этом направлении и поделиться текущими результатами наших изысканий.



Подопытный «Hello, world!» представляет собой простейшую OLTP систему:







Требования к производительности и отказоустойчивости являются ключевыми для подобных систем. Поэтому поиск решения поставленной задачи осуществлялся в направлении: C, C++, fastcgi, nginx, lighttpd, oracle. В первую очередь нам было любопытно попробовать различные варианты построения OLTP на данных технологиях, а так же измерить производительность и пиковые нагрузки.

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

В web-сервере Nginx обнаружена удаленная критическая уязвимость (CERT VU#180065, CVE-2009-2629): переполнение буфера, которое может привести к выполнению произвольного кода с правами рабочих процессов или к осуществлению атаки "отказ в обслуживании" через передачу специальным образом сформированного URL.

Уязвимые версии: 0.1.0-0.8.14. С исправлением выпущены версии nginx-0.8.15, nginx-0.7.62, nginx-0.6.39 и nginx-0.5.38. Доступен патч и обновления для Debian, Fedora, FreeBSD.

Хочу написать о небольшом трюке с 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

Коротко о нас.

Совместно с Центром телекоммуникаций и информационных технологий МГУ им. М.В. Ломоносова, мы занимаемся исследованиями DDoS.

Основная цель: разработать и донести до сообщества эффективные, доступные техники противодействия распределенным атакам на отказ в обслуживании.

В рамках исследовательской программы мы бесплатно предоставляем защиту. Все что нужно — передать трафик на наше оборудование любым удобным способом (изменить А запись DNS, GRE/IPIP tunnel).



В блоге проекта hll.msu.ru мы будем регулярно публиковать материалы, полученные в ходе исследований. Самые интересные случаи, методики, распространенные ошибки, — публиковать на Хабре.

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