Maxim Dounin wrote:
>> 1) если стоит директива limit_req_log_level notice;
>> то в error_log о limits не пишитеся вообще ничего.
>> (Linux 2.6.18-164.11.1.el5.028stab068.3 nginx/0.8.34)
>>
>
> error_log при этом включён с каким уровнем логгирования?
>
error_log /var/log/nginx/error.log notice;



>> Т.е. как видно на основе ответов курла и записей в error_log,
>> каждый последующий запрос обрабатывается в среднем на секунду
>> больше, чем предыдущий, по истечению моего burst=10,
>> получаю 503, что законно.
>>
>> каждый мой последующий запрос должен задерживаться на минуту
>> (согласно rate=1r/m) или N минут если это N запрос в пределах burst.
>> В принципе текущее поведение с задержкой на секунду сделано вполне
>> мудро, но вопрос в том, как оно на самом деле должно
>> обрабатываеться.
>> Фича\баг ?
>>
>
> Бага. Чтобы получить описанный в доках CBR должно задерживаться
> на (сейчас в корзине) / rate, по факту задерживается на (сейчас в
> корзине).
>
> Впрочем, мне лично всегда казалось вообще неправильным пытаться
> задерживать запросы. Возможности для DoS'а это только
> увеличивает. Гораздо правильнее использовать описанный в доках
> nodelay.
>
>
это верно,
я его и использую для обычных клиентов ;)

но понимать как в целом работает нужный модуль - никогда лишним не будет.

да и burst без nodelay по сути будет являться неким backlogом для бекенда,
и может использоваться чтобы лимитировать нагрузку на бекенд.

Ведь если ботнет ломанется на сервак, и будет слать по пачке запросов с
каждого айпишника
раз в несколько минут - то delay тут как нельзя лучше. (дальше
скриптами анализируем
error и access log на предмет агресивных ботов - и блокируем на уровне
nginx, а лучше firewall)

А для обычных клиентов - nodelay, определенно.

Благо, делить клиентов, как оказалось, совсем не так сложно, спасибо вам!


_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru