Re: Реализация multiple limit_req

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Wed, Dec 14, 2011 at 09:58:55PM +0400, Валентин Бартенев wrote:

> On Wednesday 14 December 2011 20:24:24 Maxim Dounin wrote:
> > On Wed, Dec 14, 2011 at 07:39:19PM +0400, Валентин Бартенев wrote:
> > > On Wednesday 14 December 2011 18:22:26 Maxim Dounin wrote:
> > > > Давай для начала распишем последствия обычного "последовательного"
> > > > применения лимитов, чтобы было понятно что так нельзя.  Или,
> > > > наоборот, можно, но с какими ограничениями.
> > > > 
> > > > Что касается принципа, то он мне не нравится: нам либо нужно всё
> > > > это делать держа локи (deadlock expected), либо имеем race между
> > > > проверкой и обновлением (и, опять же, локи придётся брать два
> > > > раза, что тоже не очень хорошо).
> > > 
> > > В limit_conn у нас также локи берутся дважды, и тут, на первый взгляд,
> > > всё можно сделать по тому же принципу.
> > 
> > В limit_conn они второй раз берутся, когда мы откатываем лимиты -
> > либо по завершению запроса, либо по наступанию на лимит.  И race'а
> > там соответственно нет.
> >
> 
> Тут мы тоже можем сделать "откат лимитов", которые не были применены.
> 
> Срабатывает лимит - сохраняем его delay и указатель на него, проверяем 
> дальше, 
> если находим лимит с большим delay, сохраняем новые значения и делаем откат 
> лимита, за которым был установлен предыдущий delay.
> 
> Если находим лимит, который должен отклонить запрос - отклоняем запрос и 
> делаем 
> откат лимита за которым был установлен delay (если ранее такой был), 
> прекращаем
> дальнейшую проверку.
> 
> Я лишь говорю о принципиальной возможность реализовать по предложенной схеме.
> В остальном - убедил. См. ниже.

Ну если свести схему к "атомарно применяем лимиты (не применяем, 
если хотя бы один сработал)" - то да, это принципиальная 
возможность "реализовать по предложенной схеме".  :)

> [...]
> > 
> > Вот как раз в примере выше - подобное поведение вполне нормально,
> > при условии правильного порядка лимитов.  Мы хотим пускать людей
> > на сайт, пока не превышен лимит на этот сайт, и мы хотим отсекать
> > людей с ^R, чтобы они вообще никому никаких проблем не доставляли.
> > Т.е. конструкция
> > 
> >     limit_req <per-ip>;
> >     limit_req <per-host>;
> > 
> > не должна никак считать в per-host лимит запросы, отклонённые на основании
> > "ip-адресом не вышел".  И в то же время должна считать суммарный
> > лимит для хоста, и отклонять при необходимости запросы за него
> > выходящие.
> > 
> 
> Озадачил, я думал-думал, но пока так и не смог придумать удачного 
> контр-примера,
> который бы не решался правильным порядком. Если так и не смогу придумать, то
> сделаю последовательную проверку до первого срабатывания. Плюсы очевидны: 
> проще, 
> меньше локов и, соответственно, быстрее.

Минусы, в общем, тоже очевидны: как минимум оно начинает зависить 
от порядка указания в конфиге, что плохо.

Я, впрочем, подозреваю, что хорошие контрпримеры существуют.

Maxim Dounin

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru