Re: Улучшение ngx_http_limit_req_module

[Валентин Бартенев]

On Wednesday 03 February 2016 00:31:21 Pavel V. wrote:
> Здравствуйте, Валентин.
> 
> >> Перевод в боевой режим может только уменьшить число запросов, поступающих на
> >> учет нетестовые зоны, что является ожидаемым поведением в силу более жесткого
> >> ограничения во включаемой зоне.
> >> 
> > [..]
> 
> > Да, и это влияние на учет запросов в других зонах может сказаться на
> > поведении.
> 
> > Скажем вот в такой конфигурации:
> 
> >   location /one {
> >       limit_req zone=soft; # rate=100r/s
> >       limit_req zone=hard; # rate=1r/s
> >   }
> 
> >   location /two {
> >       limit_req zone=soft; # rate=100r/s
> >   }
> 
> > Переключение limit_req zone=hard из режима dry-run в основной по вашей
> > схеме может привести к тому, что в location /two начнет попадать существенно
> > больше запросов.
> 
> > Этот эффект может быть нежелателен.
> 
> Такой эффект не зависит от схемы, может произойти и в случае, если в "location
> /one" будет добавлена директива "limit_req_dry_run on;", и в случае, если
> "limit_req zone=hard;" будет просто добавлена, без тестирования вовсе.
> 
> > Переключение .. может привести к тому, что в location /two начнет попадать
> > существенно больше запросов.
> > ... , а dry-run работающий в рамках  одной зоны его просто не покажет.
> 
> Эффект заключается в том, что ограничение в location /two сможет _пропускать_
> существенно больше запросов. Однако возникает вопрос - откуда они возьмутся,
> чтобы его смог показать какой-либо из режимов тестирования?
> 
> >> Цель добавления зоны test -  увидеть, какое количество запросов будет
> >> задержано/отклонено, если мы уменьшим rate с 2r/s до 1r/s в зоне one.
> 
> > А вот и не получится увидеть.  1r/s в режиме dry-run может отклонить
> > существенно меньше запросов, чем в обычном режиме.  Произойти это может
> > из-за того, что часть запросов, которые могли бы попасть под ограничение
> > в zone=test будут отклонены в зонах one и two.
> 
> Да, согласен - при наличии отклонений в зонах one и two количество увидеть не
> получится. Часть запросов (по одинаковому ключу) в зоне test не будет учтена, т.к.
> сработает ограничение зоны test, а часть не будет учтена, т.к. сработает
> ограничение зоны one.
> 
> Чтобы подсчитать количество, необходимо добавлять в limit_req_zone параметр
> warn_rate, в limit_req - warn_burst, а затем вести подсчеты превышений
> ограничений по этим параметрам параллельно основным подсчетам. Такой вариант
> когда-либо рассматривался?
> 
> Однако я исхожу из предположения, что мы имеем зону one, которая не ограничивает
> никого лишнего, и хотим убедится, что изменение её настроек также никого лишнего
> ограничивать не будет. Также предполагаем, что со второй зоной two тоже всё в
> порядке и она также никого лишнего не ограничивает.
> 
> Для этих целей мы заводим зону test с таким же ключем, как и в зоне one.
> 
> Т.е. все манипуляции тестирования нацелены на детектирование факта отсутствия
> предупреждений от тестовой зоны, в условиях отсутствия предупреждений от боевых
> зон.
> 
> В этих условиях отсутствия (критически малого числа) отклонений запросов в зонах
> one и two предлагаемый мной подход по оценке применимости настроек зоны test
> вполне жизнеспособен и весьма актуален.
> 
> 
> > Работа ограничений в зонах one и two изменится при выключении dry-run в
> > зоне test.
> 
> По задумке, в боевой режим будут переводиться _параметры_, а не зона
> test - т.е. по результатам теста будет производиться коррекция параметров зоны
> one, а зона test будет удалена.
> 
> 
> >> Я думаю, что вполне понятно то, что если в контексте есть ограничение с зоной
> >> one с rate=2r/s, то добавление ограничения с тестовой зоной test с rate=3r/s не
> >> покажет "количества ограничений", но это и не ожидается и не требуется.
> 
> > Зависит от критерия, по которому производится ограничение.
> 
> Предполагается, что у тестируемой и боевой зоны одинаковый критерий.
> 

Да идея то вполне понятна, тут вопрос в том, а оправдывает ли цель такие
сложности и будет ли этим кто-то пользоваться, кроме пары человек.

Замечу еще что поведение клиентов может меняться в зависимости от ограничений
и задержки, так что тестирование в этом случае опять же не поможет предсказать
результаты.

Хочется следующего:

 1. Чтобы легко включалось в типичном случае, когда хочется протестировать
    ограничения в конкретном location к конкретному ресурсу;

 2. Реализация была простой, не усложняла алгоритмику модуля.

Шанс быть принятым у простого патча гораздо выше.

Предлагаю начать с limit_req off.  По опыту, есть высокая вероятность, что
на этом энтузиазм и закончится.

--
Валентин Бартенев