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

Pavel V. pavel2000 на ngs.ru
Вт Фев 2 13:23:19 UTC 2016


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

> Это не может быть параметром 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 at ngs.ru



Подробная информация о списке рассылки nginx-ru