Lodger: /* Nginx: */

2008-03-11T12:42:51Z

Nginx:

← Предыдущая		Версия 12:42, 11 марта 2008
Строка 1:		Строка 1:
-	== Nginx: ==	+	== Nginx: мечта сисадмина ==
	''ЧАСТЬ 1 Интернет немыслим без web-сервера. 60-70 процентов узлов Сети обслуживаются Apache, а как живут оставшиеся 20-30 процентов?		''ЧАСТЬ 1 Интернет немыслим без web-сервера. 60-70 процентов узлов Сети обслуживаются Apache, а как живут оставшиеся 20-30 процентов?
	'''Валерия Комиссарова''' знает ответ.''		'''Валерия Комиссарова''' знает ответ.''

Lodger: Новая: == Nginx: == ''ЧАСТЬ 1 Интернет немыслим без web-сервера. 60-70 процентов узлов Сети обслуживаются Apache, а как жив...

2008-03-11T12:36:07Z

Новая: == Nginx: == ''ЧАСТЬ 1 Интернет немыслим без web-сервера. 60-70 процентов узлов Сети обслуживаются Apache, а как жив...

Новая статья

== 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 будет посвящена следующая статья.

LXF94:nginx - История изменений

Lodger: /* Nginx: */

Lodger: Новая: == Nginx: == ''ЧАСТЬ 1 Интернет немыслим без web-сервера. 60-70 процентов узлов Сети обслуживаются Apache, а как жив...