Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: limit_req
Maxim Dounin wrote:
>
> Просьба писать новое письмо для создания нового треда, а не
> отвечать на старое. Иначе не относящиеся друг к другу письма
> сваливаются в один тред, "это неправильно" (c). Спасибо.
Приношу извинения, забыл вычистить In-Reply-To и References из
хедеров.
>
> > 1. В http://forum.nginx.org/read.php?21,171264,171276#msg-171276 очень
> > доходчиво изложен принцип работы, спасибо Максиму. Но не совсем
> > понятно, как интерпретировать сообщения в логах. Например
> >
> > 2011/09/04 19:39:16 [error] 69112#0: *3786228 limiting requests, excess:
> > 16.330 by zone "one", client: XXXXXX
> >
> > Что такое *3786228 и какой физический смысл значения excess? В
> > http/modules/ngx_http_limit_req_module.c смотрел, сильно понятнее не
> > стало.
>
> Excess - это текущее количество запросов, скопившееся в "корзине".
> Если оно больше параметра burst - запросы будут отбрасываться.
Я тоже так подумал, но не понимаю, как количество запросов может быть
дробное.
>
> > 2. Какие оптимальные значения rate и burst, чтобы не мешать обычному
> > интерактивному браузингу и нормальным поисковикам, и в то же время не
> > позволить бешеным скриптам и качалкам DoS-ить backend? Установка
> > limit_req планируется только на динамические страницы. Пока поставил
> > rate=16r/s и burst=16. В логах вижу довольно много "delaying requests"
> > и изредка "limiting requests".
>
> Зависит от того, что именно лимитируется и как это что-то
> используется у вас на сайте. Если ставить ограничение только на
> динамические ресурсы, и просмотр страницы пользователем - это
> один запрос к динамическому ресурсу (+ несколько нелимитированных
> запросов к статитке), то для живых людей должно хватать rate=1r/s
> + burst=10. Ибо редкий живой человек может просматривать страницы
> с частотой более одной страницы в секунду, а если и сможет - то
> врядли он выдержит такой темп больше нескольких секунд.
Есть еще ситуация нескольких живых людей за NAT или proxy, не хотелось
бы их сильно ущемлять. Почему и спрашиваю про best practice.
> Если же один просмотр страницы пользователем выливается во много
> обращений к динамическим ресурсам (e.g. AJAX туда, AJAX сюда, плюс
> динимаически генерируемых картинок загрузить и т.п.), и все они
> лимитированы - то соответственно цифры будут совсем другие.
О том и вопрос - какие? Как правильно их оценить и как вычислить
(например по логу), что надо бы их подкрутить.
Понятно, что если при быстром нажатии F5 в браузере вылезает 503 -
значит перестарался с rate limit. Но это крайний случай.
>
> В любом случае я бы рекомендовал использовать "limit_req ...
> nodelay", от задержки обычно больше вреда чем пользы (хотя и
> существуют специфические ситуации, где она полезна).
Можно об этом поподробнее?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:sudakov@xxxxxxxxxxxxxxxx
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|