ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ограничение активных коннектов на один ip адрес



Да и вообще к бекэнду - начиная со второго подключения надо в очередь
ставить. Так как операция на бекэнде если и блокируемая, то на те же
самые ресурсы блокируется - так что распараллеливание только вредит.
Вроде бы ближе всего по наработкам к решению такой задачи mod_accel -
надо только научить его при принятии решения о постановке запроса в
очередь смотреть на пару (remote_addr, http_host), ну и отучить давать
503.

On 3/11/06, GribUser <grib@xxxxxxxxxxx> wrote:
>
> Это малость более кровожадно, чем следовало бы. По-настоящему актуальная
> задача - ограничить число АКТИВНЫХ соединений. К примеру, нужно обеспечить
> каждого клиента одним соединением с бэкэндом. При этом не важно, сколько
> соединений у него к статике и уж тем более не нужно давать отлуп для второго
> и прочих соединений. Просто каждому клиенту выделить один активный сокет, а
> остальные в режиме ожидания, как делает апач при исчерпании maxclients и,
> видимо, nginx при загруженности всех воркеров. Но сейчас очередь обработки
> живет своей жизнью, а вот в ней бы было здорово порядок наводить - кого-то
> всегда ставить в конец, кому-то позволять захватывать несколько воркеров, а
> кому-то - только один. Ну и т.д.
> Сейчас такую задачу решить в принципе невозможно, приходится делать что-то
> подобное, ставя между фронтэндом и бэкэндом на разных потоках еще апач с
> maxclients 5, скажем. По крайней мере можно гарантировать, что на бэкэнд не
> посыслятся подключения с низкоприоритетного потока и этот поток не сожрет
> все ресурсы. Но даже такое нагромождение требуемого эффекта не дает - один
> герой может сожрать весь поток, причем даже без злого умысла. Уж не говоря
> про накладные расходы, геморой по администрированию и устойчивость.
> Вообще, гибкий инструмент с регуляцией числа http-соединений нужен и никакие
> IPTABLES с reject тут не помогут. И то, что тема ограничения числа
> соединений всплывает с завидным постоянством - тому подтверждение. Десятое
> подключение можно отреджектить, но второе же так убивать нельзя. Я бы даже
> на четвертое руку не поднял.

--
Alexey Polyakov


 




Copyright © Lexa Software, 1996-2009.