![[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-22 06:32 am (UTC)К сожалению, апач (во всяком случае mpm_prefork) крут именно тем, что активно использует механизм copy-on-write. Это дает кучу бенефитов в плане секьюрити, но плохо кончается когда в долгоживущие процессы начинают грузить скриптовый байткод, который с точки зрения ядра является данными.
К сожалению, за 20 лет, которые эта проблема существует, никто так и не придумал, как подружить интерпретаторы с COW. Они не умеют разделять свой сегмент данных на "вечные" страницы, куда загружен байт-код библиотек, и которые должны шариться между процессами, и "быстротекущие", в которых лежат данные текущего запроса. Поэтому "вечные" страницы (которых на порядок больше) не шарятся и память расходуется в страшных количествах.
Поэтому апач имеет смысл там, где динамики мало. И эта динамика должна быть CGI. Процесс, куда грузится сайт-специфичный (пишущийся по месту и потенциально ненадежный) код, должен быть убит после обработки одного запроса.
Кстати. пухлость браузеров имеет ту же природу. Нынешние браузеры это в первую очередь интерпретаторы - XUL, javascript, css, И имеют те же проблемы c неумением разделять код и данные. Что еще усугубляется проблемой недоверенного кода.
no subject
Date: 2018-08-22 09:48 am (UTC)...HTML5 :)))
Пользователи хотят красивостей и мышовой интерактивности и не согласны тупо вводить текст в прямоугольные формочки, как 20 лет назад. Я сам не готов, если что ;)
Тот, кто полнее соответствует ожиданиям пользователей, выигрывает рынок. Банальный капитализм, в общем.
no subject
Date: 2018-08-22 02:12 pm (UTC)> интерпретаторы с COW. Они не умеют разделять свой сегмент данных на "вечные" страницы, куда
> загружен байт-код библиотек, и которые должны шариться между процессами, и "быстротекущие", в
> которых лежат данные текущего запроса. Поэтому "вечные" страницы (которых на порядок больше) не
> шарятся и память расходуется в страшных количествах.
ну так это (в принципе) решается прекомпиляцией байткода в один большой файл, который можно mmap'нуть.
C другой стороны -- с долгоживущими процессами уже хочется уходить от интепретируемых языков в сторону компиляторов (и желательно строгой статической типизации).
no subject
Date: 2018-08-22 03:50 pm (UTC)no subject
Date: 2018-08-25 06:22 pm (UTC)В частности, разделение зон ответственности администраторов системы и приложений, апгрейды приложений при их совместном функционировании в теле одного сервера и т.п. Нуегонафиг.
no subject
Date: 2018-08-26 06:29 am (UTC)Содержание кучки приложений в одной операционной системе имеет смысл только тогда, когда каждое из них используется раз в неделю. Если там хотя бы запрос в минуту, можно на каждое отдельный контейнер не пожалеть.
Кстати, тут недавно столкнулся с вопросом: "А что будет делать постгрес если юзеры захотят одновременно использовать PL/Python2 и PL/Python3?". Выяснил что пока это разные сессии то все ОК.
Выясняли, кстати, под соусом "А какие грабли нам грозят, если мы захотим перевести постгрес с многопроцессной модели на многонитевую".
no subject
Date: 2018-08-25 01:37 pm (UTC)Я про это и говорю. Это практика 90х :)
no subject
Date: 2018-08-25 02:46 pm (UTC)Современный веб является собранием людей, которые оказывают друг другу коммерческие услуги (т.е. прытаются друг друга кинуть и друг другом манипулировать).
no subject
Date: 2018-08-25 02:47 pm (UTC)