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

Валентин Бартенев vbart на nginx.com
Вт Фев 2 11:25:35 UTC 2016


On Tuesday 02 February 2016 05:45:18 Pavel V. wrote:
> Здравствуйте, Maxim.
> 
> Вы писали 2 февраля 2016 г., 0:16:37:
> >> Судя по всему, это должен быть параметр директивы limit_req_zone. Как он
> >> зовется в вашем TODO?
> > 
> > Скорее, отдельная директива, аналогично limit_req_status /
> > limit_req_log_level.
> 
> Приведу свою аргументацию, почему это должен быть именно параметр
> директивы limit_req_zone.
> 
> Функция "dry-run" необходима для того, чтобы дать возможность протестировать
> влияние ограничений на реальные запросы. В реальности в одном контексте
> будет несколько директив limit_req, и отключать применение ограничений
> необходимо будет только на части из них.
> 
> Например, у нас могут быть настроенные ограничения, но мы захотим проверить,
> как будут применяться более жесткие ограничения или вообще будем вводить
> другой ключ. Вполне естественно, что  имеющиеся ограничения мы отключать
> при этом не захотим.
> 
> Гибкости, которую может предоставить отдельная директива уровня контеста,
> для этих целей явно недостаточно. Чтобы решить данную ситуацию, можно,
> например, добавить параметр в директиву limit_req.
> 
> Однако, если возникает необходимость тестировать "как оно будет", то это
> значит, что неправильна настройка rate всей зоны и мы будем стремиться
> максимально исключать негативные последствия - т.е. будем выключать
> применение ограничения везде, где используется указанная зона, либо
> загрублять настройку rate.
> 
> В общем случае, наиболее вероятным сценарием использования функции я вижу
> именно создание дополнительной зоны  для тестирования, подключение её в
> нужные контексты (возможно, параллельно ранее сконфигурированным
> зонам/ограничениям) и собственно тестирование. Возможность задавать dry-run
> параметром limit_req для этих целей явно избыточна, поэтому я предлагаю
> вариант добавления параметра в директиву limit_req_zone.


Это не может быть параметром 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 они окажутся пропущены.

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

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

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

--
Валентин Бартенев


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