Здравствуйте.

> Это не может быть параметром limit_req или limit_req_zone, поскольку
> ограничения не работают по отдельности. Если в location задано несколько
> директив limit_req, то применяется наиболее жесткое ограничение. При этом,
> если в результате запрос отклоняется, то он не учитывается во всех зонах.

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

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

> Приведу пример:

> location / {
> limit_req zone=one; # rate = 1 r/s
> limit_req zone=two; # rate = 100 r/s
> }

> Представьте себе, что вы включили тестовый режим для zone=one, что тогда
> будет? Фактически под это ограничения могут попасть и те запросы, что раньше
> попадали под zone=two, но если раньше они были отклонены, то теперь из-за
> режима работы zone=one они окажутся пропущены.

Всё верно, мы отключили ограничение зоны one и запросы должны быть пропущены,
если их не ограничит зона two.

Предлагаемый мной вариант более гибкий в этом аспекте, им можно добиться того
же поведения, что и директивой уровня location - если нужно, то для zone=two
_тоже можно_ включить тестовый режим.

> Если же мы будем просто игнорировать работу zone=one и продолжать учитывать
> запрос в zone=two, то опять же не получим реальной картины.

Реальная картина зависит от того, как мы отвечаем внешнему миру. Если
включив параметр dry-run мы поменяем свое поведение, то абсолютно реальной
картины мы не получим никак, куда бы мы не вынесли параметр dry-run.

Не менять свое поведение как раз и позволяет вынос параметра dry-run на
уровни limit_req / limit_req_zone.

Нам реальная картина и не нужна, нам нужна оценка.

Цель включения режима dry-run - увидеть, не являются ли тестируемые ограничения
более жесткими, чем уже имеющиеся. Поэтому нам достаточно увидеть факт того,
что запросы (не)подпадают под ограничения зоны one. То, что от этого больше
запросов будет учтено в зоне two - ожидаемое явление.

> Т.е. тестировать по отдельности, без влияния на уже настроенные ограничения,
> не получится в любом случае.

В моей схеме можно добавить новую зону в тестовом режиме в дополнение к уже
настроенным ограничениям. Не понимаю, как добавление новой тестовой зоны сможет
повлиять на уже настроенные ограничения.

> Также хочется обратить внимание, что ограничения чаще всего настраиваются к
> конкретному ресурсу, т.е. под конкретный location, а следовательно и
> тестировать имеет смысл в рамках этого блока location.

Если "ограничения чаще всего настраиваются к конкретному ресурсу, т.е. под
конкретный location", то это значит, что зона выделена именно под конкретный
ресурс, а значит вынос ограничения на уровень limit_req_zone подходит для
решения задачи тестового режима.

Однако зона - штука общая, и может применяться и к разным ресурсам/location.
Например, у нас есть куча разных server {} языковых версий одного сайта и мы
знаем, что один реальный пользователь может одновременно находится на только на
одном из них - т.е. применяем одну зону сразу в большом наборе location всех
этих server {}.

Т.к. запросы одного location будут влиять на другие, то в этом случае я не вижу
целесообразности отключения ограничений на уровне одного location, не отключая
их в других. Вынос ограничения на уровень limit_req_zone подходит под эти
требования как нельзя лучше.

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

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