Чем больше я вожусь с web-сервером nginx...

[dzz]

...тем больше он мне нравится. Раньше близко не сталкивался (всю жизнь использовал апач), пришлось разобраться в рамках одного проекта. И - проникся :)

Comments

[vitus_wagner]

А вот надо внимательнее читать. Я открытым текстом написал, что CGI это для тех случаев, когда нам не нужно "приложение".

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

Ну и тем более в вебе. С волками жить по-волчьи выть. И если пользуешься для общения с пользователем stateless протоколом, стоит попытаться переформулировать задачу так, чтобы не приходилось эмулитровать state поверх него.

[dzz.livejournal.com]

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

> набор отдельных взаимодействующих утилит был бы более удобен и гибок.

Да без разницы, на самом деле. Главный вопрос - где выполняется объединяющая работу этих утилит логика. "Web-приложение" легко может быть как монолитом, так и результатом работы процесса оркестровки десятка отдельных сервисов на ESB или системы PHP-скриптов. Это уже вопрос архитектуры, который каждый раз оптимально решается по-своему.

Необходимость симулировать state поверх stateless-протокола обусловлена, в основном, тем, что нет хороших statefull-решений этой задачи для интернета, которые не требовали бы установки специального софта (помимо браузера) на клиентской стороне. То, что "браузер с JS есть всегда" - реалии нашего времени.

[vitus_wagner]

Откуда у тебя тысячи запросов к динамике в секунду?

В той архитектуре, для которой осмысленно применять апач, динамика это либо изменение данных, либо поисковый запрос.
Если у тебя тысячи запросов на изменение данных в секунду, то это сайт уровня ЖЖ с миллионами пользователей. И лимитирует его производительность ни разу не оверхед на cgi.

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

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

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

Хотя, конечно, играет роль документоориентированная модель, происходящая с ранних Mac-ов с их понятием creator в атрибутах файлов. Когда фрагмент данных (документ) намертво связывается с некоей программой, которой только и позволяется его просматривать и редактировать. "приложение" то идет как раз оттуда.

[dzz.livejournal.com]

> Если у тебя тысячи поисковых запросов в секунду, то ты, конечно, еще не Гугль, но уже сравним с Бингом или Байду.

Не обязательно. HTTP-запросы могут приходить не только от людей, но и от разного рода устройств. И они умеют плодить их довольно эффективно :)

Или тот же HTTP-видеостриминг (пользователей мало, запросов много).

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

> думать в stateless терминах разработчики не умеют

Ну, как ты реализуешь stateless-сессию? Сессия - это процесс, протяженный во времени, и его состояние нужно где-то хранить даже при реализации поверх stateless-протоколов.

[avnik.livejournal.com]

> В той архитектуре, для которой осмысленно применять апач, динамика это либо изменение данных, либо поисковый запрос.
> Если у тебя тысячи запросов на изменение данных в секунду, то это сайт уровня ЖЖ с миллионами
> пользователей. И лимитирует его производительность ни разу не оверхед на cgi.

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