После трех лет разработки, Игорь Сысоев анонсировал выход первой, публично доступной, версии, одного из лучших по соотношению производительность/функциональность http-серверов - nginx 0.1.0 (http://www.sysoev.ru/nginx/).Кратко, основные достоинства:
- изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
- гибкость конфигурации на уровне 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;
- экспериментальное ограничение скорости отдачи статических ответов;
Ниже, привожу текст краткой аннотации с сайта sysoev.ru (http://www.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."URL: http://www.sysoev.ru/nginx/
Новость: http://www.opennet.me/opennews/art.shtml?num=4442
autoconf-ы нам не писаны..
в морг! (tm)
at least atm// wbr
>autoconf-ы нам не писаны..
>в морг! (tm)autoconf не панацея. Глянув в директорию nginx/auto, складывается впечатление, что автор сознательно не пошел на использование autoconf. Про причины лучше спросить у него самого.
>>autoconf-ы нам не писаны..
>>в морг! (tm)
>
>autoconf не панацея. Глянув в директорию nginx/auto, складывается впечатление, что автор сознательно
>не пошел на использование autoconf. Про причины лучше спросить у него
>самого.autoconf не панацея и, зачастую, как граната для обезьяны. согласен. но как облегчает жизнь грамотно написанный configure при внесении софта в ports/pkgsrc - просто песня..
// wbr
>autoconf-ы нам не писаны..
>в морг! (tm)read this: http://lexa.ru/apache-talk/msg09302.html
А как насчет cgi, PHP , fastcgi ? в доках ни слова про них !
Читать умеем? нет?"ориентированного на отдачу статического контента"
без поддержки API модулей apache в морг.
что за страсть трепать языками ваще ни во что не втыкая?!nginx - единственное хоть каким-то боком приемлемое решение для массовой сдачи статики.
трындеть будете, когда сконфигурируете сервак, который выдержит тысяч десять одновременных закачек с одной физическойц тачки.
хорошо, госп. sauron?
>nginx - единственное хоть каким-то боком приемлемое решение для массовой сдачи статики.Кстати, кто-нибудь производительность nginx оценивал, как например это делалось для lighttpd (http://www.opennet.me/opennews/art.shtml?num=4419).
>>nginx - единственное хоть каким-то боком приемлемое решение для массовой сдачи статики.
>
>Кстати, кто-нибудь производительность nginx оценивал, как например это делалось для lighttpd (http://www.opennet.me/opennews/art.shtml?num=4419).
>
http://lists.lexa.ru/apache-talk/читай письма от Konstantin N. Bezruchenko
>>Кстати, кто-нибудь производительность nginx оценивал, как например это
>делалось для lighttpd (http://www.opennet.me/opennews/art.shtml?num=4419).>http://lists.lexa.ru/apache-talk/
>читай письма от Konstantin N. BezruchenkoЭто примерные оценки (ab - хреновый тест, читай сообщения от Alex Tutubalin в этой же рассылке, примерно пару месяцев назад), не видна полная картина, не известно как поведет себя lighttpd на месте nginx и наоборот. Вот бы графики посмотреть для nginx, похожие на те что есть на сайте lighttpd.
> без поддержки API модулей apache в морг.Он и не предназначен заменять апач. Он заточен под отдачу статику про большом (больше 1000) одновременны keep-alive соединениях. Иможет работать как фронтенд для сервера на котором крутится динамика.
На нем в часности работает images.rambler.ru и впроекте http://www.zvuki.ru nginx bcgjkmpetncz для раздачи mp3Почитайте лучше что про него пишут в мыйлистах http://lists.lexa.ru/apache-talk/ прежде чем кидаться такими словами.
что вы злобные такие? какие cgi php fastcgi когда автор явно пишет что это для сервер для отдачи
СТАТИЧЕСКОГО контента,
и почитайте http://lists.lexa.ru/apache-talk/
>что вы злобные такие? какие cgi php fastcgi когда автор явно пишет
>что это для сервер для отдачи
>СТАТИЧЕСКОГО контента,
>и почитайте http://lists.lexa.ru/apache-talk/Мне бы mod_caucho к нему прикрутить. И я буду счастлив :)
а он для чего? на www.caucho.com не нашел для чего их модуль нужен
>а он для чего? на www.caucho.com не нашел для чего их модуль
>нуженэлементарно Ватсон. Чтоб статический контент отдавал апач, а jsp и сервлеты отдавал resin. Все можно легко покласть в один каталог.
По-моему неплохая вещь для выдачи статичного контента
>По-моему неплохая вещь для выдачи статичного контента
и много его сейчас такого? даже статистика зачастую генерируется динамически.
ну на порносайтах например;) 99% траффика точно статика
>>По-моему неплохая вещь для выдачи статичного контента
>и много его сейчас такого? даже статистика зачастую генерируется динамически.Я уже устал смотреть на поделки в котороых не думая все лепят в динамику, хотя вполне можно (и проще!) обойтись статикой.
Последние перлы из ковыряния скриптов хостеров:
- Один умудрился вместо двух SELECT в MySQL навернуть штук 50, и потом возмущался посему все так тормозит, хотя дома на iP2800 все летало.
- Другой просто писал PHP код на SQL, т.е. вместо сохранения результата во временный массив создавал таблицы и прочие ужасы. Слава богу, что хостинг ему предоставили халявный и пинка под зад дать не составило труда.
- Третий сохранял инфомрацию по каждому реквесту в SQL, и при каждом же реквесте полностью перебирал эту таблицу.
- Четвертый, на каждый запрос пытался качать страниц 5 с чужих сайтов (погода, валюта) и при каждом запросу парсил.
- Пятый, засунул все, включая картинки, в SQL и забыл про индексы.Итог - грамотную динамику можно пересчитать по пальцам, остальное пишется в расчете 10 реквестов в день.
>- Пятый, засунул все, включая картинки, в SQL и забыл про индексы.
>
>
>Итог - грамотную динамику можно пересчитать по пальцам, остальное пишется в расчете
>10 реквестов в день.
Во как накипело ;-).
Только вот непонятно, или всего пять хостеров или "Итог" надуман ;-).Динамика была и будет, чтобы не тащить все громоздкое API, я бы посоветовал автору nginx создать более гибкую, чем в апаче, систему кеширования для обратного proxy. К примеру: по expire странички, фиксированное время, ну или какие-то сочетания в духе expire но не более и/или не менее N секунд.
У апача это сделано не гибко, приходилось формулу расчета времени хранения в кеше обьяснять web программистам ( заодно и что есть expire ), результатом стала затрата кучи времени и только часть страниц эффективно кешировалось. Гораздо проще было воткнуть минутное хранение кеша и оставить программеров в неведении.
вот вообще классный пример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
одновременных клиентах ;(
ну еще хочется... того чтения виртулаьных хостов из базюки :)