Первый публичный релиз http-сервера nginx 0.1.0

05.10.2004 11:55

После трех лет разработки, Игорь Сысоев анонсировал выход первой, публично доступной, версии, одного из лучших по соотношению производительность/функциональность http-серверов, ориентированного на отдачу статического контента - nginx 0.1.0.

Кратко, основные достоинства:

изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;

гибкость конфигурации на уровне Apache, настройка таймаутов и размеров буферов;

проксирование без кэширования;

поддержка keep-alive и pipelined соединений;

виртуальные сервера, определяемые по ip-адресу и имени;

изменение URI с помощью регулярных выражений;

модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы;

поддержка kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.4), /dev/poll (Solaris 8+), select и poll;

поддержка sendfile (FreeBSD 3.1+), sendfile (Linux 2.2), sendfile64 (Linux 2.4+) и sendfilev (Solaris 8+);

экспериментальная поддержка SSL;

экспериментальное ограничение скорости отдачи статических ответов;

В планах реализация поддержки FastCGI, SSI фильтра и поддержки кэширования для proxy модуля (функциональность mod_accel).

Ниже, привожу текст краткой аннотации с сайта sysoev.ru:

"Сервер использует два процесса - рабочий, он обрабатывает входящие соединения, и управляющий, который перезапускает рабочий процесс в случае изменения конфигурации, переоткрытия логов и аварийного завершения рабочего процесса. Кроме того, возможна работа в виде одного процесса. В этом случае при изменении конфигурации старые соединения используют прежнюю конфигурацию, а новые - новую. В принципе, в сервере одновременно может быть несколько конфигураций - старые удаляются только после того, как закроются все соединения, их использующие. Также реализована схема плавного апгрэйда сервера - по получению сигнала USR2 управляющий процесс fork()ается и загружает исполняемый файл. При этом слушающие сокеты наследуются новым сервером и он может принимать соединения наравне со старым сервером.

Рабочий процесс обрабатывает соединения, используя kqueue, select, poll и /dev/poll. Поскольку архитектура сервера модульная, то каждый из этих методов сделан в виде отдельного модуля. Собственно, и реализация протокола HTTP - это тоже набор модулей. Обработка запросов похожа на обработку в Apache - запросы проходят через несколько фаз, а ответы - через фильтры. На данный момент готово три фильтра: byte ranges (докачка), сжатие и chunked ответ. Фильтры работают с цепочками буферов, причём те из буферов, что находятся в файлах, на FreeBSD, Linux и Solaris могут выводиться с помощью sendfile. Сервер поддерживает keep-alive соединения и pipelined запросы, виртуальные сервера (ip- и name-based), умеет раздавать статику, индексы (то есть, выдачу "/index.html" вместо "/") и переписывать URI с помощью регулярных выражений. Кроме того, есть не до конца оттестированные кэш открытых файлов и кэширующий reverse proxy."

исправить +/–

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/4442-web

Ключевые слова: web, httpd, tune, speed

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (23)

1.1, klalafuda (?), 12:15, 05/10/2004 [ответить] [﹢﹢﹢] [ · · · ]	+/–
autoconf-ы нам не писаны.. в морг! (tm) at least atm // wbr

2.5, uldus (ok), 14:10, 05/10/2004 [^] [^^] [^^^] [ответить]

+/–

>autoconf-ы нам не писаны..
>в морг! (tm)

autoconf не панацея. Глянув в директорию nginx/auto, складывается впечатление, что автор сознательно не пошел на использование autoconf. Про причины лучше спросить у него самого.

3.6, klalafuda (?), 14:31, 05/10/2004 [^] [^^] [^^^] [ответить]

+/–

>>autoconf-ы нам не писаны..
>>в морг! (tm)
>
>autoconf не панацея. Глянув в директорию nginx/auto, складывается впечатление, что автор сознательно
>не пошел на использование autoconf. Про причины лучше спросить у него
>самого.

autoconf не панацея и, зачастую, как граната для обезьяны. согласен. но как облегчает жизнь грамотно написанный configure при внесении софта в ports/pkgsrc - просто песня..

// wbr

2.24, citrin (ok), 22:09, 06/10/2004 [^] [^^] [^^^] [ответить]	+/–
>autoconf-ы нам не писаны.. >в морг! (tm) read this: http://lexa.ru/apache-talk/msg09302.html

1.2, Аноним (2), 12:44, 05/10/2004 [ответить] [﹢﹢﹢] [ · · · ]	+/–
А как насчет cgi, PHP , fastcgi ? в доках ни слова про них !

2.9, nsware (?), 14:55, 05/10/2004 [^] [^^] [^^^] [ответить]	+/–
Читать умеем? нет? "ориентированного на отдачу статического контента"

1.4, sauron (?), 14:07, 05/10/2004 [ответить] [﹢﹢﹢] [ · · · ]	+/–
без поддержки API модулей apache в морг.

2.15, Банзай (??), 16:48, 05/10/2004 [^] [^^] [^^^] [ответить]

+/–

что за страсть трепать языками ваще ни во что не втыкая?!

nginx - единственное хоть каким-то боком приемлемое решение для массовой сдачи статики.

трындеть будете, когда сконфигурируете сервак, который выдержит тысяч десять одновременных закачек с одной физическойц тачки.

хорошо, госп. sauron?

3.16, uldus (ok), 16:56, 05/10/2004 [^] [^^] [^^^] [ответить]

+/–

>nginx - единственное хоть каким-то боком приемлемое решение для массовой сдачи статики.

Кстати, кто-нибудь производительность nginx оценивал, как например это делалось для lighttpd (https://www.opennet.ru/opennews/art.shtml?num=4419).

4.17, vgray (ok), 17:16, 05/10/2004 [^] [^^] [^^^] [ответить]

+/–

>>nginx - единственное хоть каким-то боком приемлемое решение для массовой сдачи статики.
>
>Кстати, кто-нибудь производительность nginx оценивал, как например это делалось для lighttpd (https://www.opennet.ru/opennews/art.shtml?num=4419).
>

http://lists.lexa.ru/apache-talk/

читай письма от Konstantin N. Bezruchenko

5.18, uldus (ok), 17:44, 05/10/2004 [^] [^^] [^^^] [ответить]

+/–

>>Кстати, кто-нибудь производительность nginx оценивал, как например это
>делалось для lighttpd (https://www.opennet.ru/opennews/art.shtml?num=4419).

>http://lists.lexa.ru/apache-talk/
>читай письма от Konstantin N. Bezruchenko

Это примерные оценки (ab - хреновый тест, читай сообщения от Alex Tutubalin в этой же рассылке, примерно пару месяцев назад), не видна полная картина, не известно как поведет себя lighttpd на месте nginx и наоборот. Вот бы графики посмотреть для nginx, похожие на те что есть на сайте lighttpd.

2.23, citrin (ok), 21:55, 06/10/2004 [^] [^^] [^^^] [ответить]

+/–

> без поддержки API модулей apache в морг.

Он и не предназначен заменять апач. Он заточен под отдачу статику про большом (больше 1000) одновременны keep-alive соединениях. Иможет работать как фронтенд для сервера на котором крутится динамика.
На нем в часности работает images.rambler.ru и впроекте http://www.zvuki.ru nginx bcgjkmpetncz для раздачи mp3

Почитайте лучше что про него пишут в мыйлистах http://lists.lexa.ru/apache-talk/ прежде чем кидаться такими словами.

1.7, vgray (ok), 14:48, 05/10/2004 [ответить] [﹢﹢﹢] [ · · · ]	+/–
что вы злобные такие? какие cgi php fastcgi когда автор явно пишет что это для сервер для отдачи СТАТИЧЕСКОГО контента, и почитайте http://lists.lexa.ru/apache-talk/

2.11, sauron (?), 15:16, 05/10/2004 [^] [^^] [^^^] [ответить]

+/–

>что вы злобные такие? какие cgi php fastcgi когда автор явно пишет
>что это для сервер для отдачи
>СТАТИЧЕСКОГО контента,
>и почитайте http://lists.lexa.ru/apache-talk/

Мне бы mod_caucho к нему прикрутить. И я буду счастлив :)

3.12, vgray (ok), 15:21, 05/10/2004 [^] [^^] [^^^] [ответить]	+/–
а он для чего? на www.caucho.com не нашел для чего их модуль нужен

4.13, sauron (?), 15:56, 05/10/2004 [^] [^^] [^^^] [ответить]	+/–
>а он для чего? на www.caucho.com не нашел для чего их модуль >нужен элементарно Ватсон. Чтоб статический контент отдавал апач, а jsp и сервлеты отдавал resin. Все можно легко покласть в один каталог.

1.8, TrecK (?), 14:49, 05/10/2004 [ответить] [﹢﹢﹢] [ · · · ]	+/–
По-моему неплохая вещь для выдачи статичного контента

2.19, Nickolay (??), 18:10, 05/10/2004 [^] [^^] [^^^] [ответить]	+/–
>По-моему неплохая вещь для выдачи статичного контента и много его сейчас такого? даже статистика зачастую генерируется динамически.

3.20, rost (?), 20:20, 05/10/2004 [^] [^^] [^^^] [ответить]	+/–
ну на порносайтах например;) 99% траффика точно статика

3.21, uldus (ok), 21:39, 05/10/2004 [^] [^^] [^^^] [ответить]

+/–

>>По-моему неплохая вещь для выдачи статичного контента
>и много его сейчас такого? даже статистика зачастую генерируется динамически.

Я уже устал смотреть на поделки в котороых не думая все лепят в динамику, хотя вполне можно (и проще!) обойтись статикой.

Последние перлы из ковыряния скриптов хостеров:
- Один умудрился вместо двух SELECT в MySQL навернуть штук 50, и потом возмущался посему все так тормозит, хотя дома на iP2800 все летало.
- Другой просто писал PHP код на SQL, т.е. вместо сохранения результата во временный массив создавал таблицы и прочие ужасы. Слава богу, что хостинг ему предоставили халявный и пинка под зад дать не составило труда.
- Третий сохранял инфомрацию по каждому реквесту в SQL, и при каждом же реквесте полностью перебирал эту таблицу.
- Четвертый, на каждый запрос пытался качать страниц 5 с чужих сайтов (погода, валюта) и при каждом запросу парсил.
- Пятый, засунул все, включая картинки, в SQL и забыл про индексы.

Итог - грамотную динамику можно пересчитать по пальцам, остальное пишется в расчете 10 реквестов в день.

4.22, Dmitry (??), 08:21, 06/10/2004 [^] [^^] [^^^] [ответить]

+/–

>- Пятый, засунул все, включая картинки, в SQL и забыл про индексы.
>
>
>Итог - грамотную динамику можно пересчитать по пальцам, остальное пишется в расчете
>10 реквестов в день.

Во как накипело ;-).
Только вот непонятно, или всего пять хостеров или "Итог" надуман ;-).

Динамика была и будет, чтобы не тащить все громоздкое API, я бы посоветовал автору nginx создать более гибкую, чем в апаче, систему кеширования для обратного proxy. К примеру: по expire странички, фиксированное время, ну или какие-то сочетания в духе expire но не более и/или не менее N секунд.

У апача это сделано не гибко, приходилось формулу расчета времени хранения в кеше обьяснять web программистам ( заодно и что есть expire ), результатом стала затрата кучи времени и только часть страниц эффективно кешировалось. Гораздо проще было воткнуть минутное хранение кеша и оставить программеров в неведении.

1.10, vgray (ok), 15:03, 05/10/2004 [ответить] [﹢﹢﹢] [ · · · ]

+/–

вот вообще классный пример

Andrew Kopeyko <kaa@rambler-co.ru>

Я почти год использую nginx на http://www.zvuki.ru/ для отдачи *.mp3
За вчера их скачали 436818 штук при среднем размере файла 2-3 мегабайта.
Клиенты тянут очень долго - получается 600-700 одновременных соединений,
до 1500-2000 в пиках.
Машина создаёт трафик 50-60 МБит/с, бывают пики до 82-85 МБит/с (100BaseT).
Использую 5 рабочих процессов - по числу шпинделей с контентом.
При этом nginx не создаёт нагрузки на машину:
kaa@zvuki$ top -d 1|grep nginx
50129 www          2   0 12704K 12352K RUN    0  10:27  0.05%  0.05% nginx
50130 www          2   0 11252K 10900K kqread 0  10:16  0.00%  0.00% nginx
50133 www          2   0 11436K 11088K kqread 0  10:12  0.00%  0.00% nginx
50131 www          2   0 13548K 13200K kqread 2   9:57  0.00%  0.00% nginx
50132 www          2   0 12356K 12008K kqread 0   9:44  0.00%  0.00% nginx
kaa@zvuki$ uptime
14:38  up 89 days,  1:59, 4 users, load averages: 0,47 1,10 1,38
kaa@zvuki$

Апачем не получалось отдавать более 25 МБит/с - свопился при 250-300
одновременных клиентах ;(

2.14, sauron (?), 15:57, 05/10/2004 [^] [^^] [^^^] [ответить]	+/–
ну еще хочется... того чтения виртулаьных хостов из базюки :)

игнорирование участников | лог модерирования

Добавить комментарий

Текст: