Активный рост Nginx

>Это backend падает, а не nginx :-)

Ну, просто когда в качестве бэкенда fastcgi, то за его работоспособностью lighttpd следит сам (он же и поднимает нужное число серверов), а в nginx приходится это делать со стороны, самому. Отсюда на lighttpd-серверах бэкенд всегда наличествует (если упадёт - то лайти его перезапустит... Да и, обычно, вообще перезапускает через каждые N запросов, дабы память не текла и проч.). А в случае nginx обычно упавший бэкенд так и остаётся лежать, радуя посетителей всем теперь известной ошибкой, пока оный бэкенд не пнёт админ :)

Разделяю мнение, что правильно настроенный Apache2 зарулит всех, а 10% проигрыш в производительности это ерунда по сравнению с онанизмом по переносу нескольких десятков говноправил от mod_rewite и прочей шелухи из .htaccess'ов. Сам использую nginx, но не из-за какой-то необъяснимой любви ко всему русскому, а скорее из-за того, что нету какого-то нормального способа иметь несколько несвязанных конфигураций apache в рамках одного хоста.

>Разделяю мнение, что правильно настроенный Apache2 зарулит всех

В таком случае такого Апача не видел никто :)

а 10% проигрыш в производительности это ерунда

10% - ерунда. Два-три раза - уже нет. Это под простыми нагрузками. А если на тебя насядет тысяча человек с тормозными коннектами, Апач ляжет независимо от настроек. Да, можно вешать всякие лоад балансеры и сквиды - но зачем оно надо, если nginx или lighttpd с такой нагрузкой справятся самостоятельно?

с онанизмом по переносу нескольких десятков говноправил от mod_rewite

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

> Либо проект у тебя мелкий

У меня не один проект. Есть машинки аля shared hosting для PHP - там один apache2 и все отлично - все же кому-то нужно самое обычное и привычное окружение для пыхпыха (.htaccess'ы и mod_rewrite, например). Есть машинки, которые стримят статику в сеть с помощью nginx по 80-90 Мбит из 100 доступных.

Буквально в этом месяце был один проект на Django - из-за криворукости веб-разработчика там реально 200-300 правил mod_rewrite в конфиге, и далеко не все правила тривиальные (часть можно и с помощью sed переписать). Мне жалко того парня, который адаптировал это все под nginx.

nginx теряет посетителей на крупных проектах - из-за жутко кривой реализации http. посмотрите как падает рамблер по алексе по сравнению с тем же яндексом.

в яндексе тоже используют nginx

curl -I www.yandex.ru

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 28 Dec 2009 04:31:51 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Last-Modified: Mon Dec 28 04:31:51 2009 GMT
Content-Length: 48359
...

>Какие ваши доказательства?

Ниасилил пробить fastcgi_params, да?

такие, что чтобы nginx понял, что ответ FCGI-приложения надо отдать клиенту, 'это приложение должно (внезапно!) не послать специальный FCGI пакет nginx'у, а закрыть сокет (как в пыхпых-поделках)! О как!

Да, иначе всё заканчивается ошибкой таймаута примерно через минуту.

а как в lighttpd фильтровать запросы например по HTTP-referer? то есть возможно ли это вообще? я просто не сталкивался с lighttpd...

вы ошиблись топиком

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

Например, такие, что nginx вообще не занимается вопросом fcgi, в отличии от lighttpd :)

Как это, очень даже занимается, как FCGI клиент. Но в nginx нету FastCGI process manager'а, в отличие от lighttpd. Впрочем, вопрос его нужности в веб сервере остаётся спорным, в свете разделения backend-а и frontend-а.

> приложение должно (внезапно!) не послать специальный FCGI пакет nginx'у, а закрыть сокет

http://www.fastcgi.com/drupal/node/6?q=node/22#S5.1

flags & FCGI_KEEP_CONN: If zero, the application closes the connection after responding to this request. If not zero, the application does not close the connection after responding to this request; the Web server retains responsibility for the connection.

>> Разве нужно? Ведь есть же апач

святая наивность

>Да я всеми руками и одной левой ногой и одной правой за русское. Все что могу использую наше, включая продукты и одежды.. Я просто спросил в чем оно нужнее апача.

Теорию учите. А потом задавайте такие вопросы.

> У меня смешнее. У меня на одной из машин lighttpd за nginx'ом висит :)
Ээээ... давным-давно oops не пробовал для этих целей?

>> а nginx это ведь такой падучий сервер который постоянно выдает ошибку 502 на популярных сайтах?

Это backend падает, а не nginx :-)

Однако nginx, видимо, последний сервер-ускоритель, который вместо того, чтобы защитить бэк-енд, роняет его ;)

> за его работоспособностью lighttpd следит сам

Это все хорошо работает, когда бэкэнд на той же машине, что и лайти. А если бэкэнды на нескольких отдельных хостах?

Да и, обычно, вообще перезапускает через каждые N запросов, дабы память не текла и проч

В случае php, например, есть переменные окружения PHP_FCGI_CHILDREN и PHP_FCGI_MAX_REQUESTS. Если PHP_FCGI_CHILDREN > 0, то PHP сам следит за детьми и перезапускает их по достижении PHP_FCGI_MAX_REQUESTS запросов или если те ненормально завершаются.

А в случае nginx обычно упавший бэкенд так и остаётся лежать

:-) А я на лайти видел нечто подобное, когда наши политики ддосили друг друга. Так что все дело, видимо, в используемой конфигурации.

> а закрыть сокет (как в пыхпых-поделках)! О как!

Выключите буферизацию вывода :-)

> Однако nginx, видимо, последний сервер-ускоритель, который вместо того, чтобы защитить бэк-енд, роняет его

Чисто теоретически, как защитить бэкэнд? Если он отказывает в соединении из-за того, что все процессы заняты, не обращаться к нем в течение минуты? А что с входящими запросами делать?

>>Это лишнее, так как есть php-fpm

На настоящий момент накладные расходы по поддержке патченой версии PHP крайне велики

Настоящий момент выглядит уже гораздо лучше. Ибо есть

svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm

Nginx не умеет работать с CGI+suexec по каким-то религиозным причинам. И это громадный минус.

Что касается php, то он либо должен помереть своей смертью вместе с FastCGI, либо научиться работать как SCGI сервер. После этого Apache можно смело выкидывать на помойку за ненадобностью.

>Настоящий момент выглядит уже гораздо лучше. Ибо есть

Ну так я об этом и сказал, строчкой ниже.

И уже через каких-то пять лет (когда в основные серверные дистры запилят пых 5.3) будет ЩАСТЬЕЕЕ!

>слово «популярность» я не говорил, мне интересны данные сами по себе

Просто циферки, никак не связанные с объектами реального мира, лично мне неинтересны. Однако обсуждаемые цифры как раз претендуют на то, чтобы оценивать популярность современных web-серверов. Вопрос в том, насколько они характеризуют реальной ситуации.

так как по ней можно судить о том что nginx осознанно устанавливают для обеспечения работы 4% сайтов

Сайтов, т.е. виртхостов, а не серверов. Только на имеющихся в моей собственности доменах можно наклепать неограниченное число виртхостов — миллионы, миллиарды. И все это пойдет в копилку того сервера, который выберу. Ничего себе адекватность.

распределения погрешностей

извиняюсь, я такие словосочетания не понимаю :(

Погрешность обычно состоит из систематической и случайной компонент. В нашем случае речь идет как раз о последней. Случайная погрешность (ВНЕЗАПНО!) является случайной величиной, а случайная величина характеризуется законом распределения.

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

просто я вижу что количество хостов с lighttpd всё время падает, а количество хостов с nginx всё время растят растёт - я это понимаю под тенденцией, если вы догадываетесь что ситуация может быть обратной - даже не буду спорить, просто я не такой специалист в статистике как вы

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

А вы тоже, как большинство линуксовдминов считаете, что термин «стабильность» применим не исключительно к репозиторию дистрибутива в целом (т.е. «любой набор дерьма ставишь и работает»), но и к конкретному приложению? :)

Что мешает собрать свои пакеты, или использовать сторонние репозы (в случае Debian - тот же php53.dotdeb.org, где, кстати, fpm уже есть)?

А что куча legacy-дерьма, написанного школьниками во времена php 4.0.6, может не завестись - ну это ясное дело.

>Это все хорошо работает, когда бэкэнд на той же машине, что и лайти. А если бэкэнды на нескольких отдельных хостах?

В этом случае Лайти и Энжинкс примерно соответствуют друг другу :) Но это же только один из случаев.

А кто-то мешает взять spawn-fcgi из лайти и использовать его с nginx?

Или хочется как в иисе, чтобы вебсервер сам управлял запуском? Ну это же кривой костыль.

>А кто-то мешает взять spawn-fcgi из лайти и использовать его с nginx?

Никто. Я так и делаю. Только nginx не поднимает упавший бэкенд ;)

Или хочется как в иисе, чтобы вебсервер сам управлял запуском? Ну это же кривой костыль.

Кривые костыли - это когда Интернет пестрит 502-й ошибкой :)

100% не должен вебсервер заниматься контролем жизнедеятельности fastcgi-пула. Противоречит идеологии UNIX. Для того есть супервайзеры процессов.

не понимаю, какой алгоритм работы у nginx?

принять запрос и отдать 502 ошибку?

Или что-то более сложное?

>Противоречит идеологии UNIX.

Поверь, это в Linux не самый яркий и не самый заметный пример нарушения идеологии. Например, можно напомнить о KDE ;)

...

Зато, повторюсь, под Лайти 502-я ошибка встречается на порядки реже, чем под Энжиникс.

Что важнее, доступные сайты или идеологическая чистота? :) Мне - первое...

> не понимаю, какой алгоритм работы у nginx?

Грубо говоря, принять запрос, отдать его бэкэнду, если бэкэнд занят, если бэкэнд отверг соединение — вернуть 502.

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

> Что важнее, доступные сайты или идеологическая чистота? :) Мне - первое...

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

Кстати, Лайти хоть и быстр, но дыряв и коряв с рождения. Писан от безысходности - это понятно, но не является оправданием.

>А я их не отделяю...

В случае nginx идеологическая чистота (хотя я сомневаюсь, что Игорь о ней задумывался :D) задавила простоту и надёжность. Так что - придётся отделить и выбирать. Или надёжность и простота lighttpd, или чистота nginx ;)

Понятно, что можно настроить всё. Но далеко не все этим хотят/могут заниматься. И на практике мы видим то, что видим :)

>Кстати, Лайти хоть и быстр, но дыряв и коряв с рождения.

Возможно. Но проблем у меня с ним меньше, чем с nginx. Особенно в вопросах документации :D

> В случае nginx идеологическая чистота (хотя я сомневаюсь, что Игорь о ней задумывался :D) задавила простоту и надёжность.

Я не агитирую за nginx, если что... Вообще его не использую. Речь идёт о том, насколько грамотным в долгосрочном смысле является исполнение задачи взаимодействия любого вебсервера со бэкэндом. Я считаю, что решение от Лайти - костыль и не труЪ, как, впрочем, и сам Лайти.

>Я считаю, что решение от Лайти - костыль и не труЪ

А тебя никто не заставляет этим решение пользоваться. Подымай свой отдельный fcgi-сервер и рули им сам. Лайти будет с ним работать также, как и nginx. То, что он сам умеет рулить процессами - только фича. Ты ещё на Апач наедь за mod_php :)

как, впрочем, и сам Лайти.

Аргументов костыльности Лайти по сравнению с другими web-серверами мне ждать или нет? :)

> Аргументов костыльности Лайти по сравнению

Так багтрек и security рассылки достаточно почитать. Более чем достаточно аргументов. Апач я тоже не использую, если что... Нашёл на кого равняться.

>Так багтрек и security рассылки достаточно почитать

Это хорошо, когда багтрек и секьюрити активны. Это значит, что проект живёт и развивается.

Апач я тоже не использую, если что... Нашёл на кого равняться.

Ну, вот, трёх основных лошадок не используем - а всё туда же, критиковать :) А что же Вы используете, если не секрет? IIS? Yaws? Tomcat? Resin?

> Зато, повторюсь, под Лайти 502-я ошибка встречается на порядки реже, чем под Энжиникс.

Интересно сравнить при одинаковой конфигурации.

>Интересно сравнить при одинаковой конфигурации.

Что подразумевается под одинаковой конфигурацией?

> Это хорошо, когда багтрек и секьюрити активны. Это значит, что проект живёт и развивается.

Прямо такой однозначный вывод? Винда тоже живёт и развивается, если так можно выразиться... Но есть в истории примеры, когда изначально всё сделано правильно. Проект и живёт, и развивается, но не в муках и шишках на лбу. Qmail, dnscache.

Ну, вот, трёх основных лошадок не используем

На главную роль пробовались все «основные». Причём в разное время периодически тестировались все свежие версии. Никто не прошёл. Использую mathopd.

> Интересно сравнить при одинаковой конфигурации.

Не надо быть ясновидцем. Лайти просто ляжет и ничего не будет делать. Nginx будет живее всех живых, но... тоже никакой полезной работы совершать не будет. Те же тухлые яйца, только другого цвета.

>Лайти просто ляжет и ничего не будет делать. Nginx будет живее всех живых

Хм. Это сколько соединений нужно, чтобы положить Лайти или чтобы Нгинкс ничего не делал? 50 тыс.? 100 тыс.? На такой нагрузке, вообще-то, уже распределённую систему делать надо. А 10 тыс. одновременно они оба тянут.

> Хм. Это сколько соединений нужно,

Хватит и сотни. Здесь прямая связь есть только с поворотливостью бэкэнда. Если он может обслужить 50 запросов в секунду, то какое значение имеет возможность Лайти обслужить 10 тысяч в секуду?

В основном соответствие bin-environment и max-procs в Lighttpd параметрам, используемым при запуске php-cgi. Иными словами, одинаковое количество пулов php, одинаковое количество дочерних процессов в пуле и одинаковое максимальное количество запросов до перезапуска процессов.

Я просто слишком много видел кривых конфигураций PHP :-(

> Использую mathopd.

Для mathopd по-прежнему приходится использовать cgi-fcgi для нормального FastCGI, или что-то уже изменилось?

> Для mathopd по-прежнему приходится использовать cgi-fcgi для нормального FastCGI, или что-то уже изменилось?

FastCGI не может быть нормальным. Он ненормален по определению. Нормален во всех смыслах SCGI. Да, для FastCGI cgi-fcgi или его аналог всё ещё нужно использовать. Только не нужно делать быстрых и неправильных выводов из этого... Profile. Don't speculate (c).

> Здесь прямая связь есть только с поворотливостью бэкэнда.

Ну в случае с nginx можно разнести backend по нескольким хостам — построить распределенную систему.