Nginx - что означает определение `burst`, если есть опция` nodelay`

14

В конфигурации Nginx, когда вы хотите ограничить скорость обработки запросов с помощью limit_req_zone/ limit_req instructions, я не совсем понимаю использование этой nodelayопции.
В моем понимании, это завершает запросы выше определенной скорости, не задерживая их. Так что это похоже на burst=0. Вот почему я не понимаю следующий пример:

limit_req zone=one burst=5 nodelay;

burstопределяет количество запросов, которые могут быть отложены, так какой смысл определять burst, есть ли nodelayопция?

никола
источник

Ответы:

28

Я нахожу limit_reqдокументацию достаточно ясной.

burst задокументировано таким образом:

Чрезмерные запросы задерживаются до тех пор, пока их количество не превысит максимальный размер пакета [...]

nodelay задокументировано таким образом:

Если нежелательно откладывать чрезмерные запросы, пока запросы ограничены, следует использовать параметр nodelay.

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

  • По умолчанию (нет burst, нет nodelay) запросы отклоняются с ошибкой HTTP 503.
  • С burst, вы стек определенное количество запросов в очереди ожидания, но не обрабатывать их быстрее , чем определенных запросов в единицу времени скорости .
  • С помощью burstи nodelay, очередь не будет ждать, и пакеты запросов будут обработаны немедленно .
Бернард Россет
источник
3
Спасибо за ваше разъяснение, документация для меня недостаточно ясна.
Николас
1
Я отредактировал свой ответ, чтобы отразить документацию, цитируя его. Каждое слово тщательно взвешено в документации nginx, чтобы сделать его кратким: вот что приятно в этом.
Бернард Россет
3
Так в чем же разница между limit_req_zone $binary_remote_addr zone=flood:10m rate=6r/s; limit_req zone=flood burst=0;разрешением 6 запросов в секунду и limit_req_zone $binary_remote_addr zone=flood:10m rate=1r/s; limit_req zone=flood burst=5 nodelay;разрешением 6 запросов в секунду?
Николас
2
Просто хочу подтвердить про Бернарда. Если то, что сказал Бернард, было правильно, то с помощью burst и nodelay частота обращений к веб-серверу будет время от времени превышать заданные запросы, верно?
Jcyrss
2
@BernardRosset не могли бы вы уточнить «очередь не будет ждать» - что вы подразумеваете под этим?
Денис Горбачев
8

Комментарии к первоначальному ответу кажутся неправильными.

Вопрос в том, какая разница между, скажем, скоростью = 6r / s burst = 0 и скоростью = 1r / s burst = 5 nodelay

Ответы хороши для объяснения различия, когда опция nodelay НЕ присутствует - в этом случае запросы помещаются в очередь с пакетом, а 503 - без пакета.

Оригинальный ответ кажется точным - с помощью nodelay пакетные запросы обрабатываются немедленно. И, следовательно, единственным следствием этого является то, что нет никакой разницы между указанием burst + nodelay и просто указанием более высокого предела с busrt = 0 в первую очередь.

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

FSM
источник
Спасибо, что прояснили этот момент, который был фактически причиной моего вопроса.
Николас
Это не правильно. Прочитайте мой ответ + комментарии еще раз. Если вы все еще не видите его, давайте сделаем набросок: 6r / s для обеих конфигураций, предоставленных Николасом в комментарии к моему ответу. 1-я секунда -> оба сценария будут обслуживать 6r, но conf # 2 сохранит 5 в пакете. 2-я секунда и далее, все еще то же самое для conf # 1 (все 6r обслужены), но conf # 2 будет удалять 1 из пакета пакета в соответствии с потреблением, соответствующим ограничению скорости, оставляя место для 1r в очереди. Остальные 5r выбрасываются.
Бернард Россет
@BernardRosset: но nodelayне означает ли это, что эти запросы обрабатываются сразу, а не в очереди?
Сирида
4

С burstи nodelayуказанным мне легче понять механизм, подобный этому (наоборот, чем обычно понимают):

  1. Вы разрешаете максимум burstзапросов. При $binary_remote_addrэтом это максимальное количество запросов, которые вы принимаете с данного адреса. Каждый запрос увеличивает внутренний счетчик. Когда счетчик достигает, burstвсе дополнительные запросы отклоняются (и счетчик не увеличивается сверх burstзначения).
  2. Этот счетчик постоянно уменьшается со скоростью, указанной с помощью rate.

Эта логика предполагает, что имеет смысл указать высокое burstзначение (например, 100 и более) и низкое rateзначение (даже что-то вроде 2r / s). Это лучше обрабатывает обычный просмотр (пакет параллельных запросов, за которым следует тихий период), защищая при этом устойчивый поток запросов ботов.

Дэн
источник
1

Я задал вопрос Николя парню, который написал пост на сайте nginx. NGINX Ограничение скорости. Его ответ как ниже

При прежнем ограничении скорости nginx будет принимать последовательные запросы с интервалом в 1/6 секунды. он не примет пакет запросов, которые не удовлетворяют этому минимальному интервалу времени. С другой стороны, в последнем определении nginx примет пакет до 6 запросов независимо от временного интервала между запросами. Ссылка для ответа

Садовник
источник
Привет @Gardener и добро пожаловать на сбой сервера. Спасибо за ваш хорошо разработанный вклад. Ссылка на источник очень ценится.
Марко
0

Основываясь на превосходном ответе Дэна и исходном коде nginx , краткое описание nodelayповедения выглядит следующим образом:

  • burstсколько новых параллельных запросов разрешено.
  • rateкак много новых параллельных запросов становятся старые в единицу времени. (Это обновление происходит постепенно: один раз за запрос, но не за секунду.)
Кирилл Булыгин
источник
-2

Я предлагаю прочитать эту ветку : limit_req_zone limit by location / proxy

и этот ответ: stackoverflow

Дзодза
источник
1
Ответы только на ссылку рассматриваются как неполные в случае сбоя сервера. Пожалуйста, предоставьте полезный контент здесь, а затем ссылку в другом месте для более подробной информации, если это необходимо.
EEAA