Nginx *

Многим разработчикам знакома ситуация когда кешировать страницы сайта, скажем, на 5-10 минут нельзя всего из-за одного небольшого блочка, актуальность которого нужно поддерживать если не в реальном времени, то с временем «старения» не больше 5-10 секунд. При этом посещаемость сайта продолжает расти, растет время генерации страниц и c этим надо что-то делать…

• Вариант решения 1: Подкрутить то, до чего не доходили руки последнее полгода. Все Вас поймут и передвинут сроки на другие задачи. Вы будете в роли «Супермена» один спасать сайт от непомерной нагрузки, решая проблему «бесплатно» (без доп. вливаний в оборудование). Вам может пригодиться статья «Тюнинг nginx».
   
• Вариант решения 2: Улучшить техническую базу (докупить мозгов на сервер, улучшить дисковую систему, поставить под БД отдельный сервер). В принципе проблема не решена, а скорее отложена. Теперь у Вас есть время «окопаться» и подготовиться ко второй волне наплыва нагрузки, она будет больше и накроет сильнее.
   
• Вариант решения 3: Ваш вариант, о котором я, вероятно, узнаю из комментариев.
   

Позвольте предложить и мне проверенное и относительно простое решение на базе одной из старейших технологий в Web-разработке.

Итак, сегодня мы соберём генератор миниатюрок на базе любимого народом веб-сервера — nginx-а. Что примечательно, сделаем мы это без единого гвоздя, т.е. без единой строчки кода, не считая конфигурации.

Недавно написал топик про поддержку IPv6 в Windows 7/Vista/XP (это тут). Захотелось сделать поддержку IPv6 на своём сервере, где хостируются сайты, в итоге вот что получилось.

Я подумал что кому-то это мероприятие может быть интересно. Не пиар и не агитация.

29 мая, в субботу, в Киеве состоится мастер-класс Игоря Сысоева. Сначала будет небольшое выступление, а потом ответы на вопросы всех пришедших.

А если кто-то таки решит пойти, то регистрация тут, а с кодом habrahabr скидка 10%.

Ниже пойдет текст достойный пера К.О.

Китайский трафик велик и беспощаден. Когда какая-нибудь смешная или не очень картинка попадает в китайские блоги, провайдер colocation начинает обижаться и рассказывать про несоответствие соотношений 3 к 2 российского и зарубежного трафика.

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

Примеров реализации есть несколько (ngx_http_geo_module, ngx_http_geoip_module или обычным deny), наиболее эффективный с помощью ngx_http_geo_module и базы wipmania (http://www.wipmania.com/ru/base/)

Облегчение на одном из серверов.

… или как перейти с PHP + JavaScript на JavaScript + JavaScript

Идея реализовать проект на сервер-сайд JavaScript была уже давно. Проблема была в отсутствии подходящего серверного программного обеспечения. Существующие открытые проекты не устраивали по разным причинам. Устанавливать дополнительный модуль для Apache было не самой хорошей идеей, потому что производительность и оптимизация использования памяти при этом были бы не на высоте. С помощью jslibs можно настроить FastCGI, но очень не хотелось оставлять ни малейших шансов «502 Bad Gateway», проект ngx_http_js_module так и остался в зачаточной стадии, а ngxv8 недостаточно развит для реализации реальных приложений. Поэтому я решил сделать собственную реализацию серверного javascript. Причем постараться сразу запрограммировать всю базовую функциональность, чтобы можно было ее тестировать в условиях, близких к реальности.

В качестве основного веб-сервера было решено использовать nginx, в качестве «движка» javascript — TraceMonkey (javascript-движок из Mozilla Firefox, бывший SpiderMonkey), и написать модуль для nginx, который бы их «склеил». Ничего сложного, на первый взгляд, но очень хотелось иметь определенную функциональность (и это получилось!), чтобы можно было нормально работать дальше. Большинство идей заимствованы, кстати, из PHP.

• Корректная работа в multi-thread условиях
• Возможность выполнять скрипт, указанный в URL, а не настраивать отдельно скрипт-обработчик и функцию-обработчик для каждого location
• Возможность вызывать include(), sleep(), alert() из скрипта, использовать __FILE__ и __LINE__
• Ограничение памяти, выделяемой каждому скрипту, и времени работы скрипта
• Защита открываемых скриптом файлов, указав в настройках список разрешенных папок. Примерно как open_basedir в PHP
• Автоматический разбор данных запроса (параметров GET, POST, и, конечно же, cookies), чтобы не писать обработку данных на javascript
• Поддержка запросов application/x-www-form-urlencoded и multipart/form-data
• Поддержка basic-авторизации
• Работа с базами данных (в первую очередь, MySQL и SQLite)
• Работа с файловой системой: чтение и запись файлов, проверка существования файлов, и т.п.
• Кэширование байт-кода скриптов, как, например, в eAccelerator

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

От слов — к делу! Как скомпилировать и настроить, как протестировать и сравнить...

Конечно понимаю, что это может быть и не нужно никому, коль не нашел должного решения на просторах Интернета. Однако раньше, когда компьютеры были большими, а мы маленькими, были популярны так называемые домашние странички. У гордого индейца даже модуль под это дело есть — userdir.
Недавно (июнь, 2009) решил индейца загнать в бекенд, а фронтендом настроить nginx. Так вот готового решения для организации фронтенда для nginx'а не обнаружил. Недолго думая, почесал подбородок и накатал следующую конфигурацию к nginx'у. Представьте испытанное мною счастье когда это заработало.
Итак, задача заставить в фронтенде отдавать содержимое из хомдира пользователя — /home/user/public_html. Запрос к которому в браузере выглядит как site.name/~user:

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

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

И так у нас есть задача. Заставить работать вместе легкий веб-сервер nginx и lua(в данном случае lua через wsapi(lua web server API)-fastcgi).
Что нам потребуется? Ну для начала голова на плечах. Ну то есть не то, что бы она особо нужна, но пригодится.
А далее… А далее сервер в нашем случае с GNU/Linux на борту(но думаю что сойдет и, скажем FreeBSD), мы будем рассматривать на примере Ubuntu GNU/Linux, так сложилось исторически.

Иногда скорость роста проекта несколько выше чем скорость оптимизации веб-приложения или приобретение более мощного оборудования под backend.

Наиболее простая схема «распараллеливания» нагрузки — вынос основной нагрузки на несколько frontend. Раньше приходилось мучиться (или наслаждаться, кому как) с webdav'ами, кластерными ФС и прочими хитростями чтобы обеспечить актуальную информацию, так было до тех пор, пока не появился nginx, а точнее proxy_store и proxy_cache в нём.

Появилось желание сделать сервис подобный letitbit.net в отдельно взятой стране на окраине Европы.
Требовалось:

• позволять загружать/отдавать большие файлы;
• не позволять перепубликовывать прямые ссылки на файлы;
• ограничивать количество одновременно скачиваемых файлов.

Для реализации выбрали NGINX в связке с PHP через fastcgi.
В NGINX добавили:

1. великолепный Nginx upload module, который позволяет избежать многократное копирование загруженного файла на пути NGINX-PHP. К тому же, при небольшой доработке, возможна загрузка сразу в нужную папку, что позволяет использовать простое переименование вместо копирования в PHP
2. нужную заплатку к модулю secure_link, позволяющую делать безопасные ссылки действительными ограниченное время

PHP взяли самый обычный и запустили через spawn-fcgi.
Поставили сервачок, напихали туда штук 12 терабайтных дисков.
Программист написал PHP код, а Марис Рускулис придумал следующий трюк с rewrite для NGINX, позволяющий избежать обращение к PHP при скачивании файла.
В результате, конфигурация NGINX выглядела примерно так:
http {
limit_zone regular $zonekey 10m;
limit_zone premium $zonekey 10m;
server {
root /www/oursiteishere;
location / { try_files $uri @files; }
location ~ \.php$ { try_files $uri @files; fastcgi_stuff_here; }
location @files { rewrite ^(.*)$ /index.php?$1 last; }
location /storage/ { root /storages/; internal; }
# Location for regular users
location ~ /download/.+/(.+)/0/.+/.*/(.+)$ {
set $fname $2;
set $username $1;
set $zonekey "$binary_remote_addr $username";
limit_conn regular 1;
limit_rate '100k';
secure_link_secret megasecret;
secure_link_ttl on;
if ($secure_link = "") { return 403; }
add_header Content-Disposition "attachment; filename*=UTF-8''$fname";
rewrite ^/download/([a-f0-9]+)/([\.~0-9a-zA-Z_]+)/([01])/([0-9]+)/(.+)/.+$ /storage/$4/$5 break;
}
# Location for premium users
# Location for upload using upload module
}
}

Замечательной вещью в данном конфиге является тот факт, что при скачивании файла по сгенерированной защищённой от подмены временной ссылке (проверку осуществляет secure_link) не вызывается PHP с последующим X-Accel-Redirect.
Возможно, данное решение накладывает ограничение на присутствие логики перед непосредственной отдачей файла, но тем не менее, на мой взгляд, является довольно оригинальным трюком, позволяющим немного сэкономить на fastcgi.

Привет, хабралюди!

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

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

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

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

В этой статье я поделюсь собственным опытом построения веб-сервера, работающего на CentOS 5.3.

Что требовалось:

• Полностью избавиться от Apache. Сервер должен был выдерживать хорошую нагрузку, распределяя статику и динамику.
• Нужна была поддержка последней версии libxml, малейшее различие в версиях делало сайт абсолютно нерабочим.
• Нужен был gzip
• И еще некоторые особенности, о которых я расскажу в самой статье

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

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



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

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