Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: limit_req_module постоя нно в 503
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
|