Re: Улучшение ngx_http_limit_req_module
Валентин Бартенев
vbart на nginx.com
Вт Фев 2 13:57:41 UTC 2016
On Tuesday 02 February 2016 19:23:19 Pavel V. wrote:
> Здравствуйте.
>
> > Это не может быть параметром 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 - ожидаемое явление.
>
Ограничения не работают по отдельности, они не работают последовательно, они
работают вместе и одновременно. Когда указано несколько директив limit_req,
то результатом будет кумулятивное решение о том, следует ли отклонять запрос
или нет, и если запрос будет отклонен, то он не будет посчитан во всех зонах.
Если же запрос отклонять не следует, то вычисляется наибольшая задержка.
Невозможно добавить или убрать ограничение, не повлияв на работу остальных.
> > Т.е. тестировать по отдельности, без влияния на уже настроенные ограничения,
> > не получится в любом случае.
>
> В моей схеме можно добавить новую зону в тестовом режиме в дополнение к уже
> настроенным ограничениям. Не понимаю, как добавление новой тестовой зоны сможет
> повлиять на уже настроенные ограничения.
Если директива приводит к отклонению запроса, то он не будет учтен во всех
зонах. Если мы сделаем режим таким, что при этом запрос будет учтен, но не
будет отклонен, то это не даст нам возможности оценить работу директивы,
поскольку всё будет работать несколько не так, как если бы dry-run был выключен
и не позволит оценить реальное влияние директивы на количество пропущенных
запросов.
Если мы будем действовать также, как без режима dry-run, но только пропускать
запрос, то это повлияет на работу сервера парадоксальным образом - более
жесткое ограничение в режиме dry-run будет приводить к пропусканию сервером
большего количества запросов, чем при его отсутствии.
--
Валентин Бартенев
Подробная информация о списке рассылки nginx-ru