limit_req_module постоянно в 503

[Igor Sysoev]

On Mon, Dec 15, 2008 at 03:32:04PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Mon, Dec 15, 2008 at 02:56:27PM +0300, Igor Sysoev wrote:
> 
> > On Mon, Dec 15, 2008 at 02:49:34PM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Mon, Dec 15, 2008 at 01:41:01PM +0300, Igor Sysoev wrote:
> > > 
> > > > On Mon, Dec 15, 2008 at 02:28:28AM +0300, Maxim Dounin wrote:
> > > > 
> > > > > On Sun, Dec 14, 2008 at 02:38:35PM +0300, Igor Sysoev wrote:
> > > > > 
> > > > > > On Sun, Dec 14, 2008 at 12:24:38PM +0100, Alrond wrote:
> > > > > > 
> > > > > > > обнаружил при тестировании что при использовании limit_req_module
> > > > > > > и обычных параметрах как в примере интересный эффект возникает.
> > > > > > > Тестировал только при ограничении rate=1r/s
> > > > > > > Если просто браузером рефрешить, то все нормально, в зависимости от скорости
> > > > > > > нажатий выдает некоторое количество страниц с кодом 503, но если запустить,
> > > > > > > например, "ab -n1000", то состояние 503 не уходит потом долго после теста, я
> > > > > > > честно говоря даже дождаться не мог.
> > > > > > > так было задумано (очередь?) или это ошибка?
> > > > > > 
> > > > > > 1000 запросов со скоростью 1r/s можно сделать только за 16 с лишним минут.
> > > > > > Вот на 16 минут адрес и блокируется.
> > > > > 
> > > > > Ну вообще говоря это не соответсвует заявленному leaky bucket.
> > > > > 
> > > > > Запросы, не поместившиеся в ведро, на дальнейшее опустошение этого 
> > > > > ведра влиять не могут - ибо их там нет.
> > > > 
> > > > Возможно. Сейчас алгоритм такой:
> > > > 
> > > >      excess = 1 + excess - rate * (now - last)
> > > > 
> > > >      if excess < 0
> > > >         excess = 0
> > > > 
> > > >      сохраняем excess и время
> > > > 
> > > >      if excess > burst
> > > >         503
> > > > 
> > > >      if excess
> > > >         if nodelay
> > > >             503
> > > 
> > > -             503
> > > +             ничего не делать
> > 
> > А что это в терминах HTTP :) ?
> 
> В терминах http понятие "не обрабатывать данный запрос этим 
> модулем nginx" пока отсутствует, надо будет рассмотреть вопрос в 
> следующих ревизиях стандарта. :)

Да, это я ошибся, в этом месте действительно ничего не делается.

> > > (специально перепроверил - сейчас правильно, это ты в описании 
> > > алгоритма ошибся)
> > > 
> > > >         else
> > > >             задержка на excess
> > > 
> > > Угу, я читал.
> > > 
> > > Идея leaky bucket / token bucket состоит в том, что до достижения 
> > > burst все запросы обрабатываются, после достижения - 
> > > обрабатывается не более rate запросов, остальное отбрасывается.
> > > 
> > > Учитывать запросы которые были отброшены - можно, но это совсем 
> > > другая алгоритмика, и такой подход может привести к блокировке на 
> > > неопределённый срок, что далеко не всегда хорошо.  Пример: 
> > > банальный лимит на ip приводит к тому, что любой пользователь за 
> > > aaanet'овской проксёй может заблокировать всю проксю на любой 
> > > срок.
> > > 
> > > Надо делать как-то так:
> > > 
> > >    excess = 1 + excess - rate * (now - last)
> > > 
> > >    if excess > burst
> > >        503
> > > 
> > >    if excess < 0
> > >        excess = 0
> > > 
> > >    сохраняем excess и время
> > > 
> > >    if excess
> > >        if nodelay
> > >            ничего не делать
> > >        else
> > >            задержка на excess
> > 
> > Ты написал то же самое. На самом деле, нужно что-то делать с
> > 
> >     сохраняем excess и время
> > 
> > То есть, в случае отброшенных запросов не учитывать их в excess и last.
> 
> В том что у меня написано
> 
>    if excess > burst
>        503
> 
> делается до "сохраняем excess и время", и соответствующего 
> сохранения не происходит.

И это я не увидел тоже.

> Но в общем мысль ты понял правильно, ага.

Осталось понять, нужно ли опционально сохранить текущее поведение.
Я сколняюсь к тому, что - да, только нужно понять, как это конфигурировать.


-- 
Игорь Сысоев
http://sysoev.ru