Почему некорректно считается req_limit?

Question

[catquistador]

в блоке http {} прописан limit_req_zone $binary_remote_addr zone=test:30m rate=1000r/s;
в server { location {}} прописан limit_req zone=test burst=10 nodelay;
Тест запускаю ApacheBenchmark'ом ab -n 10000 -c 80 http://localhost:80/test

Concurrency Level: 80
Time taken for tests: 9.743 seconds
Complete requests: 10000
Failed requests: 6289
(Connect: 0, Receive: 0, Length: 6289, Exceptions: 0)
Non-2xx responses: 6289
Total transferred: 3104023 bytes
HTML transferred: 1490115 bytes
Requests per second: 1026.34 [#/sec] (mean)
Time per request: 77.947 [ms] (mean)
Time per request: 0.974 [ms] (mean, across all concurrent requests)
Transfer rate: 311.11 [Kbytes/sec] received

на выход получаю 62% провалившихся запросов. при том, что RPS едва перехватил за лимит
более того, в ряде случаев при RPS ниже лимита утекают коннекты.
В логах спам

56360 limiting requests, excess: 11.000 by zone "test", client: 127.0.0.1, server: test, request: "GET /test HTTP/1.0", host: "localhost"

не понимаю, откуда такие потери и почему в логе "excess 11.000". в моём понимании там должно быть ~1010 (rps limit + burst)

Answer 1

[ky0]

Давайте разберём самое начало процесса, когда запускается ab и в нгинкс примерно одновременно начинают лететь 80 запросов. Счётчики в этот момент по нулям, но выставлен лимит в 1000 rps, то есть запросы могут обрабатываться не чаще, чем раз в 1 мсек.

По факту, внутрь провалятся ровно 1+10=11 запросов, а остальные 80-11=69 отобьются с 503 кодом - это даже больше 62%.

В дальнейшем, поскольку запросы постепенно размажутся во времени, перестав приходить синхронно, процент отлупов снизится, но отнюдь не до ожидаемых вами (1026-1000)/1000*100%, потому что время от времени (и скорее часто, чем редко) запросы всё-таки будут приходить чаще, чем раз в 1 мсек (бурст в 10 rps можно не учитывать, он по сравнению с лимитом микроскопический) - на это намекает среднее время исполнения 0.974 мсек, делёное на 80 потоков.

Попробуйте увеличить бурст, скажем, до 500-1000 и посмотреть, как это отразится на результатах.

Comments

[Lynn «Кофеман»]

Собственно тут классическая ошибка, что человек считает 1000rps как именно 1000 и именно в секунду, а на самом деле nginx оперирует интервалами и токенами. так что 1000rps нужно читать как «не чаще 1 запроса в 0.001 сек».

Что бы было понятнее разница в понимании, можно сказать что для человека «1 запрос в секунду» и «60 запросов в минуту» воспринимаются по разному, а для nginx это одно и то же. Т. к. человек (без специальных знаний) вторую запись воспринимает как «я могу послать все 60 запросов на 59 секунде минуты», а через три секунды послать ещё 60 запросов.

[catquistador]

Спасибо!
IMO, в документации везде используется непрозрачная формулировка

used to limit the request processing rate per a defined key.

Про гранулярность и токены можно почитать нормально только в блоге на nginx.org...
установка burst в 500 ожидаемо вопрос решила

ab -n 5000 -c 510
Complete requests: 5000 
Failed requests: 5

Но остаётся ещё непонимание: как эмпирически выставлять rate-лимиты кроме как "прощупыванием" на живой конфигурации?
если я точно знаю, что 600 r/s бэк держит нормально, но на 800 начинает троттлить, то как тут пропустить ~600 (+/- 100 через burst) RPS через настройку rate limit, а не burst?

[Lynn «Кофеман»]

Ну вот тут опять вопрос что понимается под «600 r/s»
Что я в него одномоментно зашлю 600 запросов, а потом через секунду ещё 600.
Или что я более-менее равномерно в течении секунды буду засылать 600 запросов (примерно по запросу каждые 1.6ms).

[Lynn «Кофеман»]

Но в общем и целом да, все чиселки подбираются эмпирически в зависимости от вашего сервера, длительности обработки запросов и т.п.

[catquistador]

Lynn «Кофеман», это обычная бомбардировка несвязанными пользователями. нету всплесков. чисто фоновая активность и прогнозировать её нельзя. можно считать пост-фактум.
мой пойнт в чём: получается, что к реальному миру намного лучше приспособлен ключ "burst", который напрямую мапится на пользовательские коннекты. а rate, при внешней простоте, под капотом прячет непрозрачную с наскока логику и математику рассчёта.
на данный момент для себя я это вижу так: единственный вариант его настроить - включить dry-run и rate подтягивать до тех пор, пока в логе не пропадут соответствующие записи, а потом докинуть бёрста в зависимости от критичности локейшена.
Спасибо!

[catquistador]

btw, а строчка в логе

limiting requests, excess: 501.000 by zone "test"

(rate limit 1K/s burst - 500) показывает ограничение гранулярно в размере текущего "окна"? // иначе, опять-же, не понятно, почему 501

[Lynn «Кофеман»]

Но погодите, limit_req это именно «лимит», т.е. число после которого серверу станет плохо, а не среднее количество запросов которое реально приходит.

Так что если вы знаете что на 800 сервер начинает троттлить, то надо поставить 750 лимита и сколько-то (допустим 50) бурста что бы несколько одновременных запросов не ломались.

[catquistador]

Lynn «Кофеман», тогда, возможно, я снова чего-то не понимаю
сейчас выставил конфигурацию:

limit_req_zone $binary_remote_addr zone=test:30m rate=300r/s;

в локейшене

limit_req zone=test burst=50 nodelay;
proxy_pass http://localhost:8080/;

на прокси-пассе висит заглушка, с рандомным слипом 200-400мс

для теста сменил инструментарий на siege как субъективно более гибкий siege
siege localhost/test -d1 -r150 -c250 -v

Transactions: 2604
hitsAvailability: 71.76 %
Elapsed time: 10.66 secs
Data transferred: 0.49 MB
Response time: 0.27 secs
Transaction rate: 244.28 trans/sec
Throughput: 0.05 MB/sec
Concurrency: 65.27
Successful transactions: 2604
Failed transactions: 1025

с увеличением лимита до 400 rps availability поднимается до 98.40 %, но выглядит так, что и на 300 он не должен был упираться с реальным rps в 244.28 trans/sec....
насколько я понимаю - основная проблема в том, что когда реквесты размазываются по тайм юниту равномерно - мы укладываемся в лимит, но как только пачка реквестов накладывается друг на друга - привет протекший траффик и увеличение burst...
// извиняюсь, если я снова за своё, но пока полноценно концепт в голове не сложился

[Lynn «Кофеман»]

В общем, я покопался в теме, и похоже на самом деле siege не может выдерживать RPS.

Я воспользовался Яндекс.Танком (https://yandextank.readthedocs.io/en/latest/index.html) и на нём хорошо видно как nginx при превышении лимита сначала продолжает отвечать нормально пока не кончится burst, а потом начинает отдавать 503. После падения нагрузки burst постепенно восстанавливается.