Здравствуйте, Валентин.

>> Перевод в боевой режим может только уменьшить число запросов, поступающих на
>> учет нетестовые зоны, что является ожидаемым поведением в силу более жесткого
>> ограничения во включаемой зоне.
>>
> [..]

> Да, и это влияние на учет запросов в других зонах может сказаться на
> поведении.

> Скажем вот в такой конфигурации:

> 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 не
>> покажет "количества ограничений", но это и не ожидается и не требуется.

> Зависит от критерия, по которому производится ограничение.

Предполагается, что у тестируемой и боевой зоны одинаковый критерий.


--
С уважением,
Pavel mailto:pavel2000@ngs.ru

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