![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dzz
...тем больше он мне нравится. Раньше близко не сталкивался (всю жизнь использовал апач), пришлось разобраться в рамках одного проекта. И - проникся :)
dzz
dzz
Page Summary
Style Credit
- Base style: Compartmentalize by timeasmymeasure
- Theme: All Mad Here by krja
Expand Cut Tags
No cut tags
no subject
Date: 2018-08-21 05:32 pm (UTC)Если nginx использовать тем же способом, каким правильно использовать апач, он тоже будет быстрым и легким (хотя из-за принципиальной мультитредовости все же несколько более тормозным и громоздким).
Но nginx таким способом использовать нельзя. Не умеет он.
no subject
Date: 2018-08-21 05:38 pm (UTC)no subject
Date: 2018-08-21 05:49 pm (UTC)Кстати, отрицательный опыт работы с nginx есть тоже. У него webdav существенно более глюкавый, чем у апача.
no subject
Date: 2018-08-21 05:59 pm (UTC)no subject
Date: 2018-08-21 07:25 pm (UTC)no subject
Date: 2018-08-21 07:36 pm (UTC)Есть ещё просто специализированные сервера - тот же unicorn под ruby. У меня он используется в связке с nginx-ом для работы redmine (nginx обслуживает внешние запросы, unicorn висит на unix-сокете и делает рубишную часть работы).
При этом необходимый для достижения того же результата процесс прикручивания рельс и passenger-а к апачу - дело геморройное.
no subject
Date: 2018-08-21 10:52 pm (UTC)no subject
Date: 2018-08-22 06:18 am (UTC)А еще я помню времена когда nginx был модулем апача. В смысле, когда Сысоев для решения тех задач, для которых он потом написал nginx, пытался развивать mod_accel.
Кстати, потом mod_proxy вырос и почти все ради чего тогда пришлось писать отдельный модуль, научился.
А вот насчет passenger-ов равно как всяких WSGI, ajp и fastcgi - согласен - они ЕЩЕ кривее чем идея встраивания своего урезанного http-сервера в приложение и использования нормального веб-сервера как frontend-прокси.
no subject
Date: 2018-08-22 06:27 am (UTC)Я имею дело с апачем где-то с 1995-1996 и прекрасно помню, как утяжелялся его дизайн и усложнялось конфигурирование по мере "роста вместе с протоколом HTTP". Это совсем не означает, что апач - плохой сервер (на самом деле, это хороший сервер ;), просто в какой-то момент он перестал быть лёгким решением без специальных телодвижений.
no subject
Date: 2018-08-21 09:44 pm (UTC)no subject
Date: 2018-08-22 06:13 am (UTC)Но в подавляющем большинстве случаев тебе нужно отработать http-запрос, сформировать динамическую страничку и забыть все нахрен. Вот для этой ситуации CGI - идеален.
За счет некоторого оверхеда на порождение процесса ты получаешь гарантию того, что все ресурсы, котоыре ты задействовал при обработке запроса будут освобождены на уровне ядра операционной системы.
То есть CGI - это типичный unix-way, а "приложения", включая контейнеры сервлетов это даже не windows-way, это Novell-way какой-то.
CGI можно программировать тяп-ляп, не заботясь об утечках памяти, утечках дескрипторов и т.д. Процесс завершится, и ядро за тобой приберется.
То есть как и шелловские скрипты при интерактивной работе это инструмент для casual programmer, программирующего пользователя. Возникла задача - взял и решил.
А "приложения" даже если ты пользуешься каким-нибудь продвинутым фреймворком типа пирамиды или торнадо, все равно требуют куда более сложного проектирования и аккуратной работы с ресурсами.
Я уж не говорю про то, что все эти фреймворки почему-то тягатеют к порочной идее ASP "а давайте встроим код прямо в html-страницу". Особенно забавно как с этой идеей пытаются борться в php, где она встроена прямо в дизайн языка, и приходится прилагать огромные усилия, чтобы это переломить и сделать разделение кода и данных по-человечески.
no subject
Date: 2018-08-22 07:21 am (UTC)> Возникла задача - взял и решил.
А вот тут ты не прав. Всё это хорошо, когда контент stateless, а в большинстве web-приложений это не так. В результате приходится либо выстраивать забор из костылей на основе cookies, либо реализовывать сессии и некий persistеnce. Можно, конечно, держать весь сессионный контент в датабазном бэкэнде, но тут тоже дофига подводных камней.
no subject
Date: 2018-08-22 09:18 am (UTC)Я лично считаю что концепция "приложения" избыточно переоценена. И даже на десктопе и мобильных платформах приложения часто используют не по делу - там где набор отдельных взаимодействующих утилит был бы более удобен и гибок.
Ну и тем более в вебе. С волками жить по-волчьи выть. И если пользуешься для общения с пользователем stateless протоколом, стоит попытаться переформулировать задачу так, чтобы не приходилось эмулитровать state поверх него.
no subject
Date: 2018-08-22 09:44 am (UTC)> набор отдельных взаимодействующих утилит был бы более удобен и гибок.
Да без разницы, на самом деле. Главный вопрос - где выполняется объединяющая работу этих утилит логика. "Web-приложение" легко может быть как монолитом, так и результатом работы процесса оркестровки десятка отдельных сервисов на ESB или системы PHP-скриптов. Это уже вопрос архитектуры, который каждый раз оптимально решается по-своему.
Необходимость симулировать state поверх stateless-протокола обусловлена, в основном, тем, что нет хороших statefull-решений этой задачи для интернета, которые не требовали бы установки специального софта (помимо браузера) на клиентской стороне. То, что "браузер с JS есть всегда" - реалии нашего времени.
no subject
Date: 2018-08-22 10:46 am (UTC)В той архитектуре, для которой осмысленно применять апач, динамика это либо изменение данных, либо поисковый запрос.
Если у тебя тысячи запросов на изменение данных в секунду, то это сайт уровня ЖЖ с миллионами пользователей. И лимитирует его производительность ни разу не оверхед на cgi.
Если у тебя тысячи поисковых запросов в секунду, то ты, конечно, еще не Гугль, но уже сравним с Бингом или Байду. Опять же это кластерные решения, балансировка нагрузки в полный рост и узкое место ни разу не оверхед на запуск процесса при обработке запроса.
Конечно, есть еще один случай, который я не рассматриваю специально - shared хостинг, когда у тебя на одном физическом сервере тысячи сайтов. В наше время всеобщей виртуализации стоит каждом такому сайту выдать докерный контейнер, если не полноценную виртуалку.
Необходимость симулировать state в основном обусловлена тем, что думать в stateless терминах разработчики не умеют. Подавляющее большинство нынешних веб-разработчиков пришло из дельфей и вижуал васиков - из области разработки клиентов к корпоративным БД - это была предыдущая массовая программисткая ниша.
Хотя, конечно, играет роль документоориентированная модель, происходящая с ранних Mac-ов с их понятием creator в атрибутах файлов. Когда фрагмент данных (документ) намертво связывается с некоей программой, которой только и позволяется его просматривать и редактировать. "приложение" то идет как раз оттуда.
no subject
Date: 2018-08-22 11:37 am (UTC)Не обязательно. HTTP-запросы могут приходить не только от людей, но и от разного рода устройств. И они умеют плодить их довольно эффективно :)
Или тот же HTTP-видеостриминг (пользователей мало, запросов много).
Вообще, мы тут уходим от темы apache vs nginx в область системной архитектуры. Для обеспечения масштабируемости приходится использовать архитектурные решения, которые могут быть избыточными при малой нагрузке, но уверенно держать большую.
> думать в stateless терминах разработчики не умеют
Ну, как ты реализуешь stateless-сессию? Сессия - это процесс, протяженный во времени, и его состояние нужно где-то хранить даже при реализации поверх stateless-протоколов.
no subject
Date: 2018-08-22 01:59 pm (UTC)> Если у тебя тысячи запросов на изменение данных в секунду, то это сайт уровня ЖЖ с миллионами
> пользователей. И лимитирует его производительность ни разу не оверхед на cgi.
Вот к момету когда сайт дорастает до уровня жж, обычно переделывать уже поздно, а архитектура унаследована от "гостевухи" на расчитаной 5 пользователей домосети. И переделывать обычно поздно/дорого.
no subject
Date: 2018-08-22 01:53 pm (UTC)во первых -- это означает черти-что с правами (ты не набегаешься создавать по пользователю на каждый cgi-bin), во вторых с логичной структурой веб-приложения оно тоже сочетается так себе (тонна реврайтов в .htaccess? я их лично в гробу видел)
> Но в подавляющем большинстве случаев тебе нужно отработать http-запрос, сформировать
> динамическую страничку и забыть все нахрен. Вот для этой ситуации CGI - идеален.
путаете причину с следствием, cgi это такой ad-hoc когда надо было придумать хоть какое-то общение с сервером в котором будет логика на стороне сервера (а логики на стороне клиента не было вообще, js придумали уже позже)
> CGI можно программировать тяп-ляп, не заботясь об утечках памяти, утечках дескрипторов и т.д.
Вот это _плохо_, и провоцирует писать плохо и не думая.
> Процесс завершится, и ядро за тобой приберется.
и временные файлы приберет, ага.
И все хранилища корректно закроет, и приведет в консистентное состояние. Щаз.
> Я уж не говорю про то, что все эти фреймворки почему-то тягатеют к порочной идее ASP "а давайте
>встроим код прямо в html-страницу".
1 Это по моему в php как раз первые "додумались"
2 покажите мне где в пирамиде код в страницу засовывается, пирамида кстати спроектирована на удивление правильно, и в общем подталкивает к довольно прямой архитектуре приложения.
> Особенно забавно как с этой идеей пытаются борться в php, где она встроена прямо в дизайн языка,
> и приходится прилагать огромные усилия, чтобы это переломить и сделать разделение кода и данных
> по-человечески.
Ну потому что это фактически язык шаблонов, распухший до языка общего назначения.
no subject
Date: 2018-08-25 01:36 pm (UTC)А про тормозную реализацию ссл в апаче и mod_rewrite уже складывают легенды. И это уже не говоря про потребление памяти.
Увы, но апач остался в равитии далеко в 90х и уже он никогда не будет альтернативой nginx'у.
no subject
Date: 2018-08-25 02:43 pm (UTC)99% веб сайтов не являются крупными проектами и там нет необходимости в тысячах одновременных коннектов.
Если вам по делу нужен ssl (а не потому что диверсанты из гугля сказали, что "это небезопасный сайт"). то в первую очередь вам нужно защищать свои данные от соседей по хостингу.
Если у вас shared hosting, то ssl для вас - напрасная затрата машинного времени.
Я считаю что если вы делаете сайт, у которого 3000 коннектов в секунду, то вы что-то делаете неправильно.
no subject
Date: 2018-08-25 02:54 pm (UTC)Отсюда и 3000 коннектов. Не в секунду, а подключенных постоянно.
Ну и 3000 коннектов в секунду это сердненький такой хайлод, которых уж совсем не 1%
Вопрос скорости работы апача стоит не только в рамках количества нагрузки. Больше стоит стандартный вопрос скорости загрузки страниц. И апач уже давно и тут сливает с ССЛ и mod_php/fastcgi.
Игнорировать SSL потому что "диверсанты так заставляют" нельзя из-за тех же пользователей, которые тупо закроют страницу, если им браузер говорит что она не безопасна.
Увы, при всей моей любви к апачу, его разработчики обленились и по всей видимости ждут забвения своего детищя.
no subject
Date: 2018-08-25 06:24 pm (UTC)no subject
Date: 2018-08-25 07:23 pm (UTC)Тоесть теоретически ничто не мешает самому самому декодироать поток из вебсокета и рисовать на канвасе, но врядли реализация декодирования mpg4 на ЖС не будет тормозить где-то :)
Проще сделать гейт rtsp->webrtc и сделать клиента в 10 строк.