3

Привет Всем!

Из документации NGINX "Если же избыточные запросы в пределах лимита всплесков задерживать не требуется, то следует использовать параметр nodelay". То есть имея "nodelay" запросы в пределах burst будут обработаны немедленно?

Тогда есть ли разница между:

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; limit_req
zone=one burst=5 nodelay;

И

limit_req_zone $binary_remote_addr zone=one:10m rate=6r/s; limit_req zone=one;

Благодарю за ответ!

Mikhail Politaev
  • 620

1 Answers1

3

Разница есть и значительная.

В документации написано не очень внятно, но в реальности rate=6r/s означает что после успешного запроса все остальные в течении ≈0.16 секунды будут отклонены, т.е. вы не можете отправить 6 запросов сразу и подождать секунду, вы должны отправлять их по одному с перерывом в одну шестую секунды.

burst же позволяет «занять» обработчик запроса из будущего (обработать редкие всплески). Но среднее количество обработанных запросов всё равно не будет превышать заданный rate.

В ваших примерах в первом случае вы можете мгновенно получить ответы на 6 запросов, но следующий успешный запрос будет только через секунду после первого. Во втором случае вы можете обрабатывать 6 запросов в секунду, но между каждым запросом должен быть перерыв в 1/6 секунды.

Alexey Ten
  • 5,821
  • "все остальные в течении ≈0.16 секунды будут отклонены" -- откуда эта цифра 0.16? Откуда у вас это более внятное чем в документации представление, поделитесь ссылками если такие есть. – Mikhail Politaev Sep 16 '16 at 09:18
  • @MishaPolitaev В документации написано: Ограничение обеспечивается с помощью метода "leaky bucket". Можете загуглить. А 0.16 это 1/6. – Roman Sep 16 '16 at 10:03
  • Я поставил эксперименты и заглянул в код. – Alexey Ten Sep 16 '16 at 10:05
  • @AlexeyTen Только в первом примере, по идее, следующий успешный запрос будет через секунду после первого, т.к. именно тогда второй запрос освобождает место в "ведре" для одного запроса и туда тут же можно поместить следующий запрос. – Roman Sep 16 '16 at 10:12
  • @Roman поправил – Alexey Ten Sep 16 '16 at 10:17
  • @AlexeyTen "...вы можете мгновенно получить ответы на 6 запросов, но следующий успешный запрос будет только через секунду после первого." -- следующий то есть 7 запрос?

    Если бы в первом примере не было "nodelay" тогда мы бы задержали 6 запросов и обработали с промежутком 0.16 сек? А если бы не было "burst=5" то эти 5 были бы отклонены?

     – Mikhail Politaev Sep 16 '16 at 10:32
  • «следующий то есть 7 запрос» — нет, тот который придёт через секунду. Все остальные запросы в этом промежутке (хоть миллион) будут сразу отклонены. – Alexey Ten Sep 16 '16 at 10:51
  • Да, nodelay влияет только на время начала обработки запроса. Логика ограничения запросов не меняется. – Alexey Ten Sep 16 '16 at 10:52
  • Если нет burst=5, см. второй пример. – Alexey Ten Sep 16 '16 at 10:54
  • Время через которое обновляется окно обработки запросов вычисляется из rate? При rate=30r/m оно обновлялось бы каждый 2 секунды? При таком rate следующий обработанный запрос был бы через 2 секунды? – Mikhail Politaev Sep 16 '16 at 11:49
  • Когда rate=1r/s, а burst=5 и нет "nodelay". Допустим пришли 6 запросов, 1 прошёл, 5 другие стали в очередь (burst). Через секунду из очереди обработался один запрос и тут же пришел новый и стал в очередь, таким образом, если поток запросов не прекращается очередь будет всегда занята и обрабатываться со скоростью 1r/s. То есть скорость будет той же что и без burst - 1r/s если поток достаточно высок чтоб держать окно burst постоянно занятый. – Mikhail Politaev Sep 16 '16 at 11:49
  • Время через которое обновляется окно обработки запросов вычисляется из rate — Да. Это нам проще мыслить и писать в запросах в секунду, но реально это ограничение на один запрос в период t. – Alexey Ten Sep 16 '16 at 11:52
  • Именно так burst и работает. – Alexey Ten Sep 16 '16 at 11:52
  • Благодарю за объяснения! – Mikhail Politaev Sep 16 '16 at 11:58