> Нормален во всех смыслах SCGI.

Нормален, но не сказал бы, что во всех :-)

К PHP прикрутить поддержку SCGI, а принципе, не сложная задача. А с nginx сложнее.

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

Как говорится, данная тема уже выходит за рамки текущего обсуждения. Есть довольно много способов сделать load balancing и high availability. Nginx будет 101-ым в очереди по степени важности.

> К PHP прикрутить поддержку SCGI, а принципе, не сложная задача. А с nginx сложнее.

Не понял. Я всегда думал наоборот. В PHP его нет даже в планах, а в nginx'e он есть из коробки...

> В PHP его нет даже в планах

Нет, но написание SAPI-модуля не является трудной задачей.

а в nginx'e он есть из коробки

Для очень старых версий nginx есть сторонний ngx_scgi_module (http://wiki.nginx.org/NginxNgxSCGIModule), но и он полностью не соответствует спецификации SCGI.

> Нет, но написание SAPI-модуля не является трудной задачей.

Вот бы ещё кто-то взял и нетрудно написал его... Отсутствие этого модуля - это ж практически единственное оправдание, почему Апач всё ещё популярен в мире. Парадокс, но жизнь апача непосредственно в руках PHP ;)

Н-да, ЛОР не исправим в своих детских болезнях. Висели из-за кого на этот раз? Из-за апача или из-за быдложабы?

троллинг или невнимательность?

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

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

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

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

>> Что касается php, то он либо должен помереть своей смертью вместе с FastCGI

видимо, так и произойдет :-)

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

с этим он худо-бедно справляется.

просмотреть по расширению запрашиваемого файла возможность отдачи статики

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

если ни одно из собственных правил не подошло - запросить с бэкэнда и проксировать.

а вот это вообще неработоспособно. бросить запрос на бекэнд и по таймауту вернуть 502, это несерьезно.

>что-то неважное типа картинки из интерфейса

этих картинок на странице может быть штук 400, аватарки всякие, иконки, смайлики, прочая бяка, пусть лучше nginx такую мелочь отдает, чем апач будет обслуживать все эти запросы, еще и в 8-16 соединений на 1 клиента
Особенно актуально как раз для серверов где мало памяти (например vps)

а вот это вообще неработоспособно. бросить запрос на бекэнд и по таймауту вернуть 502

это проблемы не nginx , а backend

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

nginx занимает 4 Мб RSS памяти.

>этих картинок на странице может быть штук 400, аватарки всякие, иконки, смайлики, прочая бяка, пусть лучше nginx такую мелочь отдает, чем апач будет обслуживать все эти запросы, еще и в 8-16 соединений на 1 клиента Особенно актуально как раз для серверов где мало памяти (например vps)

ну 400 картинок на странице, это по любому отстой и порноресурс.

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

это проблемы не nginx , а backend

ни разу. нжтнкс просто не умеет работать с бекэндами.

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

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

>ну 400 картинок на странице, это по любому отстой и порноресурс.

хорошо, я передам кое-кому что его уютный бложик - порноресурс )
Кстати можно взять практически любой форум, там тоже куча мелкой статики в картинках (аватары и смайлы)

я вот отдаю статику с другого хоста

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

просто не умеет работать с бекэндами.

объясните что по вашему «работа с бекэндом» ?


с последнем абзацем по числу форков не соглашусь, nginx спросил страницу у апача, получил ее, connection-close, форк апача уже не занимает память, в то время как nginx может эту страничку отдавать долго и упорно. Про балансировку сами написали...
Если коротко - в системе с малым количеством памяти и ограниченным MaxClients у апача число одновременно обслуживаемых пользователей на сайте возрастает многократно, за счет nginx.
У меня впечатление , что вы сравниваете apache на хосте с 8 Gb памяти и возможностью еще и статику поставить на отдельный хост,я скорее имею ввиду ультрабюджетные vps, где пара-тройка клиентов на сайт (где еще разведена «порнография» с кучей картинок на страницу) запросто могут заставить апач сьесть всю доступную память...

>хорошо, я передам кое-кому что его уютный бложик - порноресурс )

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

объясните что по вашему «работа с бекэндом» ?

это бережная передача запоса на бекэнд и грамотная обработка всех вариантов развития событий. Количество 502 ошибок говорит само за себя...

с последнем абзацем по числу форков не соглашусь, nginx спросил страницу у апача, получил ее, connection-close, форк апача уже не занимает память, в то время как nginx может эту страничку отдавать долго и упорно.

Посчитайте на пальцах, _количество_ форков меньше не стало. Сколько запросов, столько и форков апача на бэкенде + столько же форков самого нжинкса. Другое дело, что при той же нагрузке количество параллельно висящих форков уменьшится, но де факто это мало помогает.

У меня впечатление , что вы сравниваете apache на хосте с 8 Gb памяти и возможностью еще и статику поставить на отдельный хост,я скорее имею ввиду ультрабюджетные vps, где пара-тройка клиентов на сайт (где еще разведена «порнография» с кучей картинок на страницу) запросто могут заставить апач сьесть всю доступную память...

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

>рассовой
брр...

это бережная передача запоса на бекэнд и грамотная обработка всех вариантов развития событий. Количество 502 ошибок говорит само за себя...

и как это себе представить? что должен делать бедный nginx если «бакенданама не отвесяенама! страницанама не полученама, гамно, совсем гамно бакенданама...» ? Вот и выдает 502, сам то он не может динамику генерировать, а как бы себя вел в данном случае апач ? Да тоже если нет ответа, то браузер выдает сакраментальное сообщение о том, что страница не может быть загружена.

_количество_ форков меньше не стало. Сколько запросов, столько и форков апача на бэкенде + столько же форков самого нжинкса

ой... а вы nginx то использовали? Он не форкается... увы, совсем не форкается, там 1 мастер открывает порт и запускает worker если он упадет, и N-ое количество worker процессов, для маленького сервера вполне достаточно 1 (!) воркера, для большого - по числу ядер процессора можно, но реально достаточно всего одного, и он не форкается. То же самое скажу с апачем, если до nginx у меня в ps aux выдавалось куча форков httpd, сейчас там не намного больше чем сколько указано в пределах MaxSpareServers,

Ну так популярный ресурс без аппаратных ресурсов, это же конь в вакууме

я про бюджетные решения на основе vps (форум там, бложик, по мелочи всякое) с сравнительно низкой нагрузкой на сервер, вы тут про википедию... С другой стороны , вот если взять маленький сервер, с его .. 256 М памяти, сидят на сервере около 5-8 реальных клиентов и штук 30 ботов пасутся, поисковые. спамеры всякие, апач тут уже в таком объеме памяти «на грани», а nginx вполне способен даже такой сервер вытянуть из небольшого «ЛОР-эффекта» на 150+ посетителей одновременно (можете смеяться конечно, но большому кораблю - большое плавание, а маленькой лодочке - маленькое).

Вообщем мы мерим несколько разными категориями, nginx нужен либо очень маленьким серверам, либо гигантам для раздачи статики, во втором случае может и лайти быть

>и как это себе представить? что должен делать бедный nginx если «бакенданама не отвесяенама!

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

ой... а вы nginx то использовали? Он не форкается... увы, совсем не форкается, там 1 мастер открывает порт и запускает worker если он упадет, и N-ое количество worker процессов, для маленького сервера вполне достаточно 1 (!) воркера,

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

То же самое скажу с апачем, если до nginx у меня в ps aux выдавалось куча форков httpd, сейчас там не намного больше чем сколько указано в пределах MaxSpareServers,

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

С другой стороны , вот если взять маленький сервер, с его .. 256 М памяти,

Где ж его взять-то... не могу себе представить, где оный может появиться. Ведь надо же каждый месяц платить хостеру, а тут цена вопроса - 30 уе и только ради этого реверс-прокси городить?

>ждать пока ответит. на то он и мелкий
там есть настройки таймаута в конфиге, другое дело что по умолчанию nginx долго может не ждать, это уже пинать сайтоломастеров-администраторов, чтобы делали по-нормальному, а не как бог на душу положил.

Значит он через селект раздает

да, + poll может

>там есть настройки таймаута в конфиге, другое дело что по умолчанию nginx долго может не ждать,

таймаут здесь не при чем. Это слишком грубо для программы, основная, если не единственная задача которой в том и состоит, чтобы буферировать нагрузку. Он должен сам соображать, что раз нагрузка большая, то надо таймаут увеличить, он же фронтендом и стоит.

да, + poll может

да хоть epoll. разница минимальна. Зачем ставить нжинкс+ апач, если можно обойтись одним лайти?

>Зачем ставить нжинкс+ апач, если можно обойтись одним лайти?

с тем же успехом можно обойтись одним nginx, вопрос предпочтений

>просто я вижу что количество хостов с lighttpd всё время падает, а количество хостов с nginx всё время растят растёт

а где посмотреть такую статистику? как для сайта определить веб-сервер?

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

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

>+ poll может

да хоть epoll. разница минимальна.

ololololololol

раздай мне селектом или поллом статику одновременно 10 тысячам слоупоков на модемах

у лайти странный конфиг, чувствуется пхп :) хотя привыкаешь.

у nginx же классический юниксовый (похоже на bind, dhcpd, logrotate и т.п.). все непонимание происходит при попытках переноса убогих (т.е. завязанных на реврайт, а не на location) конфигов апача напрямую, без осмысления.

что же касается local fastcgi, то специализированный обработчик для данного приложения/скриптового языка часто лучше, чем универсальный внутренний. тот же php-fpm умеет многую php-специфику - плавный рестарт, пулы для разных uid/gid, защита от повреждения shared memory акселераторов, лимиты, отдельные настройки для каждого пула - в общем, похапешный говнокод на нем гонять куда удобнее :). хотя, конечно, свой менеджер, опционально собираемый, и не помешал бы.

>по крайней мере в части организации виртуальных хостов.

Кхм. Вот уж с чем вопросов не было даже без заглядывания в документацию :)

> таймаут здесь не при чем. Это слишком грубо для программы, основная, если не единственная задача которой

Как раз и при чём. send_timeout как настроишь, так и будет. Но не стоит забывать про такое же ограничение в браузере. Он тоже ждёт не вечно запрошенную страницу. Кажется, не более 2-х минут.

Что касается единственного предназначения nginx'a, оно заключается в максимально быстрой отдаче, а не в максимально долгом ожидании ответа бэкенда.

А ещё стоит отличать 502 (бэкенд умер) от 504 (ответа бэкенда не дождались). 502 не лечится на стороне фронтэнда никак и от типа его не зависит - будь то апач или nginx или лайти - разницы нет.

Страницы 502/504 потому раздражают людей, что они не по-человечески написаны, а ленивые админы не удосужились подставить соответствующие странички, написанные человеческим языком. Например: «Извините, сервер в данный момент перегружен. Зайдите к нам позже».