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

[Igor Sysoev <is@xxxxxxxxxxxxx>]

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

> (специально перепроверил - сейчас правильно, это ты в описании 
> алгоритма ошибся)
> 
> >         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.


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