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. По опыту, есть высокая вероятность, что на этом энтузиазм и закончится. -- Валентин Бартенев _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru