Apache mpm itx

PHPSID, да ну? ))). А, вы до сих пор используете mod_php? Тогда мы идем к вам =)

Raistlin,

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

при правильной настройке, атакуемый сайт отвалится а остальные будут пытаться работать.

Для этого не нужен новый mpm.

... для этого нужна новая операционная система! 🤪 (cloudlinux)

А ничего, что там чуть больше чем "лимитировать количество воркеров" для виртуального хоста?

И может я чего-то не понял, но весь пук этого cloud (ну почему не нано, ы?) - делается обычными cgroups. Не знаю, насколько хуже чем сделали они с openvz, зато cgroups есть в ядре. Есть и модуль апача mod_cgroups для шаред-хостинга.

Это не имеет смысла -- создание одного узкого места искуственно ведёт к проблемам в других местах. Например, если мы настроим для виртхоста обработку запросов через leacky bucket, то у нас может переполниться backlog. То же самое и с другими ресурсами.

Поэтому сейчас они исследуют новую возможность -- выставлять большие лимиты и запускать специальный демон, который будет следить за потреблением ресурсов и применять санкции к пользователям, которые потребляют слишком много. Напоминает парсинг bsd accounting, да? :)

Нано актуально только в России, а cloud -- везде.

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

mod_cgroup не изучал подробно, но беглый взгляд на исходники говорит, что процесс совсем легко может выйти из своей группы. CloudLinux в этом месте хотя бы требует секретную uint32_t cookie, и при неверном её указании убивает процесс.

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

mod_qos в помощь

Почему "искуственно ведет"? Не настроим - не приведет что-ли? Backlog переполнится еще быстрее, если мы не будем быстро принимать запрос к обработке и решать отпинать-ли его с 503 какой-нибудь или обработать нормально.

backlog - он же для всех, по определению. Там все-равно нельзя лимитировать нагрузку для конкретного виртуалхоста.

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

В любом случае, на название проекта много фантазии не потрачено ;)

Ну, эт маркетинг.

Не смотрел пока на модуль подробно - не знаю насколько это фатально связано с его дизайном. Больше похоже на детскую болезнь.

Почему? Я так понимаю, трудность в другом - найти кому дать следующий реквест обработать.

Читайте внимательнее -- "leacky bucket" как раз придерживает соединение в некоторой очереди, пока не будут обработаны другие соединения для этого сайта. К этому же ведёт ограничение на процент процессора -- вместо того, чтобы бросить все ресурсы сервера на обработку, соединения одного пользователя будут копиться, лишая других пользователей других ресурсов (например, память, io (так как, возможно, чем дольше будет выполняться процесс, тем чаще его данные будут вымещаться из дискового кеша, тем чаще ему придётся лезть за ними на диск)).

Маркетинг-не маркетинг, а почти все пользователи CL, которых я знаю, пользуются им из-за этого.

Т.е. перекидывать запросы между процессами апача?

Я просто не понимаю о какой очереди идет речь. Если "leacky bucket" работает уже после того, как апач начал обрабатывать запрос и понял для какого он хоста/пользователя - это вроде как уже бессмысленно. Там все просто, никакой очереди: либо работаем нормально, либо отфутболиваем с каким-нибудь 503.

Видимо, вы о том что в подобной ситуации что-то типа leacky bucket в апаче работает на этапе принятия соединения. Там ничего не известно про виртуальный хост, так что действительно все общее. Не решить это, наверно, одним вебсервером.

Ну, грубо говоря - да. Собственно, и itk ведет себя как ведет - именно по аналогичной причине.