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