LXF94:nginx
|
|
|
Содержание |
Nginx: мечта сисадмина
ЧАСТЬ 1 Интернет немыслим без web-сервера. 60-70 процентов узлов Сети обслуживаются Apache, а как живут оставшиеся 20-30 процентов? Валерия Комиссарова знает ответ.
Web-сервера бывают разные – получше, похуже или вовсе предназначенные для решения нескольких типов задач. Выбрать web-сервер, полностью соответствующий именно вашим нуждам, просто необходимо: от этого во многом зависит, насколько хорошо – эффективно и удобно для пользователей – будет функционировать ваш web-ресурс. Соответственно, правильный выбор и поддержка web-сервера – известная «головная боль» почти всех администраторов в мире. В заголовок данной статьи вынесено название продукта, который мы будем рассматривать; наверное, однозначно назвать его «мечтой администратора» – некоторое преувеличение. Но, без сомнения, Nginx – неплохой выбор для попытки приблизиться к главному желанию сисадмина почти любого ресурса: стабильно и эффективно работающему web-серверу.
Кое-что о Nginx
Прежде чем говорить об этой разработке, давайте разберемся, что же такое Nginx и какова его история.
Nginx – HTTP-сервер (и одновременно – почтовый прокси-сервер, но об этом позже). Сразу же уясните для себя важную деталь: Nginx не является стандартным web-сервером в том смысле, в каком большинство читателей могут его воспринять, т.е. Nginx не может служить функциональной заменой, например, Apache или IIS. В сущности, Apache и Nginx находятся «по разные стороны баррикад». Здесь уместно вспомнить модель «front-end/back-end»: соответственно, Apache будет относиться к back-end, а Nginx – к front-end. Данные продукты предназначены для выполнения задач различных типов – это очень важно.
Почему мы говорим исключительно об Apache? Да потому, что Nginx работает только под Unix/Linux системами. Теперь об истории проекта. Nginx начал разрабатываться Игорем Сысоевым (одним из администраторов Rambler’а) весной 2002 года. Проект стал использоваться на различных серверах (в частности, в том же Rambler’е) задолго до официального релиза, состоявшегося 4 октября 2004 года, и до своего обнародования Nginx уже прошел серьезное тестирование. По данным, собранным и организованным Алексеем Тутубалиным, в марте 2006 года щелчок по «Черному квадрату» (http://www.rukv.ru) приводил к отклику Nginx в 9,8%, а в марте 2007 – уже в 22,7% случаев (речь идет о виртуальных серверах). Помимо Rambler’а, стоит упомянуть о Mamba и Peterhost, на чьих серверах также функционирует Nginx.
Когда пригодится Nginx?
В чем преимущества использования модели «front-end/back-end»? Основное – значительно б льшая эффективность работы, чем в других – стандартных и привычных – схемах использования того же Apache; но отнюдь не во всех.
Прежде всего необходимо учесть, что использование обсуждаемой модели будет уместно только применительно к серверам с высокой нагрузкой, оправдывающей использование подобного рода средств. Под «высокой нагрузкой» следует понимать количество http-запросов, превышающее 10–12 в секунду. Соответственно, если такой нагрузки на сервер нет, то лучше не строить работу сервера по принципу «frontend/back-end»; это решение может привести и к некоторому замедлению работы (хотя и довольно незначительному): ведь Nginx – дополнительный «пропускной пункт» на пути к back-end’у и к увеличению потребления памяти и т.д. Не стоит использовать Nginx там, где в нем нет нужды, чтобы не винить в неудобствах и неувязках продукт и его разработчика.
Что умеет Nginx?
Итак, какие возможности предоставляет данный продукт? Nginx – это и HTTP-сервер, и почтовый прокси-сервер. Поэтому рассматриваемые возможности оправданно разбить на категории согласно двум функциональным направлениям Nginx. Начнем с HTTP-сервера, в числе функций которого:
- Обслуживание статических запросов. Конкретнее, это «передача» пользователю статических html-страниц, графических изображений и
прочего контента. Второе – обслуживание запросов на индексные файлы. Данная функциональность реализуется модулем ngx_http_index_module: он обслуживает запросы, оканчивающихся слэшем (“/”).
- Автоматическое создание списка файлов; это задача модуля ngx_http_autoindex_module, который выполняет автоматическое создание
листинга каталога. Запрос попадает к модулю в том случае, если у компонента ngx_http_index_module возникли проблемы с поиском индексного файла.
- Ускоренное проксирование без кэширования, выполняемое модулем ngx_http_proxy_module. Он обладает большим количеством директив, с помощью которых можно настроить параметры процесса. В следующий раз мы рассмотрим этот вопрос более подробно.
Особого внимания заслуживают функции/модули, касающиеся обеспечения отказоустойчивости виртуального сервера и распределения нагрузки. Данная функциональность связана с модулем ngx_http_upstream.
Предусмотрена еще и поддержка SSL.
Что же касается «почтовой» функциональности, то здесь имеются возможности для нормальной работы с IMAP, POP3, SMTP, а также SSL. Среди поддерживаемых методов аутентификации: LOGIN для IMAP, USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5 у POP3, и AUTH LOGIN PLAIN CRAM-MD5 у SMTP.
Чего Nginx «не умеет» и вряд ли будет «уметь»? Судя по «настрою» разработчика, о .htaccess придется забыть. Не стоит надеяться и на поддержку CGI.
Что осталось добавить? Возможность обновления исполняемого файла Nginx и его настроек без остановки процесса обслуживания клиентов; высокая модульность. Среди приятных «мелочей» – быстрая ротация журналов, ведение отладочного журнала, и перенаправление ошибок (например, 404).
Почему Nginx так быстро работает?
А теперь давайте посмотрим, почему Nginx (как и сама модель «frontend/back-end») работает быстро и эффективно (Nginx действительно быстр, это не «слухи»). Можно поставить вопрос и так: почему разделение обязанностей между Apache/Nginx обеспечивает большее быстродействие, чем в схеме работы без последнего?
Почему – если сравнивать работу Apache без Nginx и в связке с Nginx в ситуации со статическим контентом – второй вариант быстрее (иногда это заметно больше, иногда меньше, но чувствуется всегда)? Рассмотрим, что такое модель prefork(ed), используемая в Apache 1.3. Мы имеем один главный процесс, который при получении входящих запросов создает требуемые дочерние процессы с помощью fork (). Такой подход традиционен, и в то же время является одним из худших по производительности/эффективности. Почему? Происходит серь- езный перерасход системных ресурсов (думаю, не нужно объяснять сущность работы fork()). И бороться с тем, что множество дочерних процессов (число которых, понятное дело, растет с числом запросов) стремительно поглощает системную память, негативно влияет на производительность и в разы снижает удобство работы с ресурсом, очень трудно. Что же нам предложит Nginx? FSM! Аббревиатура расшифровывается как Finite State Machine – автоматы с конечным числом состояний, иначе – КА (конечные автоматы). Несмотря на ряд ограничений, в ситуации с Nginx FSM полностью себя оправдывает. FSM – довольно сложная вычислительная модель; ей посвящен не один толстый книжный том; ну, а мы просто посмотрим, что еще используется в отношении скорости в Nginx, и к какому результату, заметно отличающемуся от prefork(ed)-модели, это все приводит.
Nginx использует kqueue (на системах Free/Net/Open BSD и MacOS X) – механизм оповещения определенного процесса о конкретных событиях, произошедших в ядре ОС. Применение kqueue, в частности, позволяет избавиться от большого количества «лишних» вызовов некоторых функций. Также используются epoll и rtsig (в ОС Linux), sendfile (для Linux, FreeBSD, Solaris). На примере kqueue очевидно направление этих функций. Главное – результат: радикальное уменьшение количества «съедаемой» памяти, увеличение быстродействия и т.д., со всеми вытекающими последствиями.
Эффективность модели «front-end/back-end» напрямую следует из осуществления значительного снижения воздействия негативных сторон prefork(ed) Apache. Разделение труда между front-end и back-end дает радикальное уменьшение числа переключений контекста и количества потребляемой памяти.
На самом деле возможностей у Nginx намного больше, чем здесь описано. Говорить о них можно если и не бесконечно, то достаточно долго. Но задача данной статьи – рассказать, насколько многообразен и качественен этот web-сервер; детальному рассмотрению процесса установки и настройки Nginx будет посвящена следующая статья.
