Dizzy Journal (Live)

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

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

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

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

From:

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

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

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

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

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

From:

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

...HTML5 :)))

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

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

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

From:

avnik.livejournal.com

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

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

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

From:

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

From:

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

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

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

From:

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

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

Кстати, тут недавно столкнулся с вопросом: "А что будет делать постгрес если юзеры захотят одновременно использовать PL/Python2 и PL/Python3?". Выяснил что пока это разные сессии то все ОК.

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

From:

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

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

From:

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

From:

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

From:

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

From:

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

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

From: