Dizzy Journal (Live)

ну сложно быть более громоздким чем апачь

From:

Тут вопрос не только в тяжеловесности, но и в удобстве конфигурирования некоторых вещей.

From:

Я с трудом могут назвать программу, менее громоздкую чем апач. У меня сейчас у апача RSS около мегабайта.

Вы его просто готовить не умеете.

From:

любой из браузеров? (ну может кроме links)

From:

Чего-чего? У бразуеров нынче RSS гигабайтами измерется. А апач - быстрый и легкий. Если его правильно использовать.

Если nginx использовать тем же способом, каким правильно использовать апач, он тоже будет быстрым и легким (хотя из-за принципиальной мультитредовости все же несколько более тормозным и громоздким).
Но nginx таким способом использовать нельзя. Не умеет он.

From:

пардон, у меня менее в более почему-то трансформировалось в голове.

From:

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

Кстати, отрицательный опыт работы с nginx есть тоже. У него webdav существенно более глюкавый, чем у апача.

From:

ну когда-то был отрицательный, а потом я окончательно перешел на nginx, а собственные проекты обычно имели собственный http и либо жили сами, либо за reverse proxy

From:

Собственные (кривые и недоделанные) http-сервера - это бич сегодняшнего интернета.

From:

Ну, апач и nginx когда-то были яркими представителями того же самого явления :)

Есть ещё просто специализированные сервера - тот же unicorn под ruby. У меня он используется в связке с nginx-ом для работы redmine (nginx обслуживает внешние запросы, unicorn висит на unix-сокете и делает рубишную часть работы).

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

Edited Date: 2018-08-21 07:42 pm (UTC)

From:

Апач апачу - люпус эст.

Если повыкидывать почти все модули - будет лёгким и относительно быстрым (хотя, статику nginx таки быстрее раздаёт). Если вкрячить в него тот же mod_php и активно юзать соответствующие скрипты - в мегабайт RSS не уложится, и в два тоже.

В общем, готовить умеем, просто всякому овощу - свой фрукт.

Edited Date: 2018-08-21 07:41 pm (UTC)

From:

ну так под "собственный" имеется ввиду что-то более менее стандартное влинкованое. И они обычно с обработкой запросов приложения справляются. И это таки менее криво чем cgi-bin.

From: (Anonymous)

apache ровно так же можно прикрутить к unicorn (благо, тот стандартный http-сервер). но незачем т.к. nginx в этой роли более уместен.

From:

alexkuklin.livejournal.com

Ух, из анабиоза кто-то вышел ;)

From:

Нет, это более криво, чем cgi-bin. Потому что возникает понятие "приложения". Я согласен, что в некоторых случаях оно полезно. Иногда (очень редко) долгоживущее состояние, оформленное в виде долгоживущего процесса нужно.

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

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

То есть CGI - это типичный unix-way, а "приложения", включая контейнеры сервлетов это даже не windows-way, это Novell-way какой-то.

CGI можно программировать тяп-ляп, не заботясь об утечках памяти, утечках дескрипторов и т.д. Процесс завершится, и ядро за тобой приберется.

То есть как и шелловские скрипты при интерактивной работе это инструмент для casual programmer, программирующего пользователя. Возникла задача - взял и решил.

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

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

From:

Вот не надо. Я работаю с апачем более 20 лет, а начинал еще с NCSA httpd. Апач никогда не был наколенным поделием, он начинался как набор патчей к по-моему церновскому httpd. И он рос ВМЕСТЕ с протоколом httpd.

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

Кстати, потом mod_proxy вырос и почти все ради чего тогда пришлось писать отдельный модуль, научился.

А вот насчет passenger-ов равно как всяких WSGI, ajp и fastcgi - согласен - они ЕЩЕ кривее чем идея встраивания своего урезанного http-сервера в приложение и использования нормального веб-сервера как frontend-прокси.

From:

Давай не будем меряться фоссилиями :)

Я имею дело с апачем где-то с 1995-1996 и прекрасно помню, как утяжелялся его дизайн и усложнялось конфигурирование по мере "роста вместе с протоколом HTTP". Это совсем не означает, что апач - плохой сервер (на самом деле, это хороший сервер ;), просто в какой-то момент он перестал быть лёгким решением без специальных телодвижений.

Edited Date: 2018-08-22 06:29 am (UTC)

From:

Зима близко... :)

From:

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

К сожалению, апач (во всяком случае mpm_prefork) крут именно тем, что активно использует механизм copy-on-write. Это дает кучу бенефитов в плане секьюрити, но плохо кончается когда в долгоживущие процессы начинают грузить скриптовый байткод, который с точки зрения ядра является данными.

К сожалению, за 20 лет, которые эта проблема существует, никто так и не придумал, как подружить интерпретаторы с COW. Они не умеют разделять свой сегмент данных на "вечные" страницы, куда загружен байт-код библиотек, и которые должны шариться между процессами, и "быстротекущие", в которых лежат данные текущего запроса. Поэтому "вечные" страницы (которых на порядок больше) не шарятся и память расходуется в страшных количествах.

Поэтому апач имеет смысл там, где динамики мало. И эта динамика должна быть CGI. Процесс, куда грузится сайт-специфичный (пишущийся по месту и потенциально ненадежный) код, должен быть убит после обработки одного запроса.

Кстати. пухлость браузеров имеет ту же природу. Нынешние браузеры это в первую очередь интерпретаторы - XUL, javascript, css, И имеют те же проблемы c неумением разделять код и данные. Что еще усугубляется проблемой недоверенного кода.

From:

> CGI можно программировать тяп-ляп, не заботясь об утечках памяти, утечках дескрипторов и т.д. Процесс завершится, и ядро за тобой приберется.
> Возникла задача - взял и решил.

А вот тут ты не прав. Всё это хорошо, когда контент stateless, а в большинстве web-приложений это не так. В результате приходится либо выстраивать забор из костылей на основе cookies, либо реализовывать сессии и некий persistеnce. Можно, конечно, держать весь сессионный контент в датабазном бэкэнде, но тут тоже дофига подводных камней.

Edited Date: 2018-08-22 07:23 am (UTC)

From:

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

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

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

From:

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

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

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

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

Edited Date: 2018-08-22 09:54 am (UTC)

From:

>Нынешние браузеры это в первую очередь интерпретаторы - XUL, javascript, css...

...HTML5 :)))

Пользователи хотят красивостей и мышовой интерактивности и не согласны тупо вводить текст в прямоугольные формочки, как 20 лет назад. Я сам не готов, если что ;)

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

Edited Date: 2018-08-22 09:52 am (UTC)

From:

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

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

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

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

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

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

From:

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

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

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

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

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

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

From:

> Нет, это более криво, чем cgi-bin.

во первых -- это означает черти-что с правами (ты не набегаешься создавать по пользователю на каждый cgi-bin), во вторых с логичной структурой веб-приложения оно тоже сочетается так себе (тонна реврайтов в .htaccess? я их лично в гробу видел)

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

путаете причину с следствием, cgi это такой ad-hoc когда надо было придумать хоть какое-то общение с сервером в котором будет логика на стороне сервера (а логики на стороне клиента не было вообще, js придумали уже позже)

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

Вот это _плохо_, и провоцирует писать плохо и не думая.

> Процесс завершится, и ядро за тобой приберется.

и временные файлы приберет, ага.
И все хранилища корректно закроет, и приведет в консистентное состояние. Щаз.

> Я уж не говорю про то, что все эти фреймворки почему-то тягатеют к порочной идее ASP "а давайте
>встроим код прямо в html-страницу".

1 Это по моему в php как раз первые "додумались"
2 покажите мне где в пирамиде код в страницу засовывается, пирамида кстати спроектирована на удивление правильно, и в общем подталкивает к довольно прямой архитектуре приложения.

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

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

From:

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

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

From:

> К сожалению, за 20 лет, которые эта проблема существует, никто так и не придумал, как подружить
> интерпретаторы с COW. Они не умеют разделять свой сегмент данных на "вечные" страницы, куда
> загружен байт-код библиотек, и которые должны шариться между процессами, и "быстротекущие", в
> которых лежат данные текущего запроса. Поэтому "вечные" страницы (которых на порядок больше) не
> шарятся и память расходуется в страшных количествах.

ну так это (в принципе) решается прекомпиляцией байткода в один большой файл, который можно mmap'нуть.

C другой стороны -- с долгоживущими процессами уже хочется уходить от интепретируемых языков в сторону компиляторов (и желательно строгой статической типизации).

From:

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

From:

Причем ядерная.

From:

Дорогой Витус, при всем уважении к вам, апач даже рядом не стоял в роли ssl/прокси. Апач превращается в неповоротливую тывку уже при 3000 коннектах.
А про тормозную реализацию ссл в апаче и mod_rewrite уже складывают легенды. И это уже не говоря про потребление памяти.
Увы, но апач остался в равитии далеко в 90х и уже он никогда не будет альтернативой nginx'у.

From:

Поэтому апач имеет смысл там, где динамики мало. И эта динамика должна быть CGI. Процесс, куда грузится сайт-специфичный (пишущийся по месту и потенциально ненадежный) код, должен быть убит после обработки одного запроса. Кстати. пухлость браузеров имеет ту же природу. Нынешние браузеры это в первую очередь интерпретаторы - XUL, javascript, css, И имеют те же проблемы c неумением разделять код и данные. Что еще усугубляется проблемой недоверенного кода.

Я про это и говорю. Это практика 90х :)

From:

99% веб сайтов не являются крупными проектами и там нет необходимости в тысячах одновременных коннектов.
Если вам по делу нужен ssl (а не потому что диверсанты из гугля сказали, что "это небезопасный сайт"). то в первую очередь вам нужно защищать свои данные от соседей по хостингу.

Если у вас shared hosting, то ssl для вас - напрасная затрата машинного времени.

Я считаю что если вы делаете сайт, у которого 3000 коннектов в секунду, то вы что-то делаете неправильно.

From:

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

From:

:) я согласен. Но количество трафика ростет. И чтоб сейчас зарабатывать на жизнь нужны решения которые нужны именно этим людям.

From:

Я по своей специфике работы очень много использую SSL из-за webrtc и как следствие веб сокетов.
Отсюда и 3000 коннектов. Не в секунду, а подключенных постоянно.
Ну и 3000 коннектов в секунду это сердненький такой хайлод, которых уж совсем не 1%

Вопрос скорости работы апача стоит не только в рамках количества нагрузки. Больше стоит стандартный вопрос скорости загрузки страниц. И апач уже давно и тут сливает с ССЛ и mod_php/fastcgi.
Игнорировать SSL потому что "диверсанты так заставляют" нельзя из-за тех же пользователей, которые тупо закроют страницу, если им браузер говорит что она не безопасна.

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

From:

если убрать из апача mod_php/etc, mod_rewrite то какой толко остается от апача? :)

From:

Hy там ещё до чёрта разных mod_ :)))

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

From:

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

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

Edited Date: 2018-08-25 07:42 pm (UTC)

From:

Кстати, как там в webrtc, нормальная поддержка RTSP появилась? Вопрос не праздный, реально интересно.

From:

если честно, то я не в курсе. RTSP по-мойму из коробки через вебсокеты поддерживать никто не собирается. Вебртц -- это узкозаточенный комплект SIP+SRTP+DTLS + ICE и больше ничего. А вебсокеты это просто сокеты для отсылки бинарщины или текста.
Тоесть теоретически ничто не мешает самому самому декодироать поток из вебсокета и рисовать на канвасе, но врядли реализация декодирования mpg4 на ЖС не будет тормозить где-то :)
Проще сделать гейт rtsp->webrtc и сделать клиента в 10 строк.

From:

то что оно привычнее это факт. К счастью доки по nginx как по-мне, так намного проще и понятнее написаны. А для совсем тупых прямо кукбуки есть.
Я наверное до позапрошлого года пользовался апаче везде, а потом как посмотрел в сторону nginx'а один раз, так и сразу все понял :)

From: