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

[Maxim Dounin <mdounin@xxxxxxxxxx>]

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
+             ничего не делать

(специально перепроверил - сейчас правильно, это ты в описании 
алгоритма ошибся)

>         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

Maxim Dounin