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

[Maxim Dounin <mdounin@xxxxxxxxxx>]

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 и время", и соответствующего 
сохранения не происходит.

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

Maxim Dounin