ПРОЕКТЫ 


  АРХИВ 


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: 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


 




Copyright © Lexa Software, 1996-2009.