Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK

[Konstantin Lepikhov <lakostis@unsafe.ru>]

Hi Vitaly!

On 10/30/15, at 11:37:49 AM you wrote:

> Konstantin Lepikhov писал 2015-10-30 2:09:
> ...
> >> Но MaxClients задаёт ограничение на количество процессов, общее для
> >> всех пользователей и хостов.
> >>
> >> Есть параметр MaxClientsVhost, который можно указывать в конфиге 
> >> сайта.
> >> Но между ними большое отличие в поведении:
> >> При превышении MaxClients Apache просто не реагирует на коннекты к
> >> нему, таким образом накапливается очередь подключений,
> >> и пользователи при перегрузке испытывают замедление реакции сайта.
> > А цель какая? Ограничить кол-во подключений или кол-во процессов? 
> > Если
> > подключения, то да, limit_req в nginx для каждого vhost'а, если 
> > процессы,
> > то крутить cgroups.
> Цель — ограничить количество одновременных процессов, обрабатывающих 
> запросы к конкретному сайту.
> limit_req даёт возможность ограничить количество обращений в секунду, и 
> таким образом
> может защитить от внешнего врага. Мне же нужно защититься от врага 
> внутреннего.
> Если сайт вместо 200мс начнёт отвечать за 10с (не важно по каким 
> причинам), всё не должно рухнуть от
> количества процессов апача и не должны пострадать соседи по апачу 
> (другие сайты).
> А cgroups будет давать ошибку при форке? И помешает другим процессам 
> под этим же UID.
Был какой-то патч для cgroups, который как раз ограничивал кол-во форков,
но его надо допиливать под текущие ядра, мне предлагали это сделать под
wks ядра, но у меня нет времени и желания этим заниматься.

https://lists.unsafe.ru/pipermail/kernels/2013-September/000382.html

> 
> >> А ограничение по MaxClientsVhost сразу возвращает 503 при достижении
> >> предела подключений. Что вовсе не желательно, потому
> >> что для клиента выглядит как то, что сайт работает быстро, но иногда
> >> вместо страницы — ошибка.
> >>
> >> Может быть есть всем известное решение, которое я не знаю?
> >>
> >> Другой вариант — это научить nginx ошибку 503 не передавать клиенту, 
> >> а
> >> ждать и пытаться получить от бэкенда более корректный ответ.
> > в этом случае nginx должен что-то ответить клиенту вместо 503 
> > (поскольку
> > "ждать" он не умеет), что тоже не есть гуд.
> Ну умеет же nginx proxy_next_upstream, и ждать он может, если ему не 
> отвечать (при достижении ограничения через MaxClients).
> 
> Я для себя пока сделал вывод, что либо MaxClientsVHost должен уметь 
> переводить запрос в очередь, как это делается при достижении MaxClients,
> либо nginx должен уметь ждать и делать повторы. Он умеет это при 
> нескольких upstream (там есть и timeout и количество попыток и код 
> ошибки 503 понимает).
> Видимо, это либо платная функциональность (в nginx Plus есть слово 
> queue), либо достижима через расширение.
у nginx есть proxy_limit_rate и встроенный perl, через который
можно сделать обработку 503 и таймаутов. _limit_rate поможет не отдавать
данные быстро, что позволит не понижать время ответа.

-- 
WBR et al.