18

In the Nginx configuration, when you want to limit the request processing rate by using the limit_req_zone / limit_req instructions, I don't really understand the use of the nodelay option.
In my understanding, it terminates the requests above the defined rate without delaying them. So it seems equivalent to burst=0. That is why I don't understand the following example :

limit_req zone=one burst=5 nodelay;

burst defines the number of requests which could be delayed, so what is the meaning to define burst if there is the nodelay option?

6 Answers 6

29

I find limit_req documentation clear enough.

burst is documented that way:

Excessive requests are delayed until their number exceeds the maximum burst size [...]

nodelay is documented that way:

If delaying of excessive requests while requests are being limited is not desired, the parameter nodelay should be used

Requests are limited to fit the defined rate. If requests are incoming at a higher rate, no more than the defined number of requests per time unit will be served. You then need to decide on what to do with those other requests.

  • By default (no burst, no nodelay), requests are denied with an HTTP 503 error.
  • With burst, you stack the defined number of requests in a waiting queue, but you do not process them quicker than the defined requests per time unit rate.
  • With burst and nodelay, the queue won't be waiting and request bursts will get processed immediately.
10
  • 3
    Thanks for your clarification, the documentation isn't clear enough for me.
    – Nicolas
    Nov 11, 2014 at 21:40
  • 3
    So what is the difference between limit_req_zone $binary_remote_addr zone=flood:10m rate=6r/s; limit_req zone=flood burst=0; which allows 6 requests per second and limit_req_zone $binary_remote_addr zone=flood:10m rate=1r/s; limit_req zone=flood burst=5 nodelay; which also allows 6 requests per second ?
    – Nicolas
    Nov 13, 2014 at 16:23
  • 2
    Just want to confirm about Bernard's anwser. If what Bernard said was correct, With burst and nodelay, the r/s rate of hit the webserver will be more than the defined requests from time to time, right?
    – Jcyrss
    Jan 28, 2015 at 9:09
  • 2
    @BernardRosset could you please clarify the "queue won't be waiting" — what do you mean by that? Jul 25, 2015 at 11:28
  • 2
    This answer made me feel stupid. So I just tested out a rate limit of 1r/s. With a burst of 50, if I sent 100 requests concurrently, I get 50 requests rejected, and the other 50 complete one by one every second. With "nodelay" added, 50 still get rejected, by the other 50 complete concurrently instead of one by one. Sep 9, 2017 at 17:47
8

The comments on the original answer seem wrong.

The question at hand is what the difference between, say rate=6r/s burst=0 and rate=1r/s burst=5 nodelay

The answers are great about explaining the difference when the nodelay option is NOT present -- in which case, the requests queue up with the burst, and are 503'd without the burst.

The original answer seems spot on -- with nodelay, the burst requests get processed immediately. And thererfore, the only implication of that is that there is NO difference between specifying a burst + nodelay vs. just specifying a the higher limit with busrt=0 in the first place.

Therefore, to more succinctly answer the OP question: the meaning of burst when nodelay is specified is the same as just specifying a larger rate without burst.

4
  • Thanks to have clarified this point, which was effectively the reason of my question.
    – Nicolas
    Aug 1, 2015 at 10:13
  • 1
    This is wrong. Read my answer + comments again. If you still do not see it, let's make sketch: 6r/s on both configurations provided by Nicolas in a comment on my answer. 1st second -> both scenario will serve 6r, but conf #2 will store 5 in burst. 2nd second and onwards, still the same for conf #1 (all 6r served), but conf #2 will have removed 1 from the burst bucket according to a consumption fitting the rate limit, leaving space for 1r in the queue. The other 5r are thrown away. Jan 30, 2017 at 14:51
  • @BernardRosset: but with nodelay, won't that mean those requests are processed immediately instead of queued?
    – siride
    Jan 10, 2018 at 20:55
  • @BernardRosset - please can you clarify about the above question - but with nodelay, won't that mean those requests are processed immediately instead of queued?
    – variable
    Feb 16, 2022 at 4:46
8

With burst and nodelay specified I find it easier to understand the mechanism like this (the other way around than it is usually understood):

  1. You allow a maximum of burst requests. With $binary_remote_addr that's the maximum number of requests that you accept from a given address. Every request increases an internal counter. When the counter reaches burst all additional requests are denied (and the counter is not increased beyond burst value).
  2. This counter is continuously decreased at a rate specified using rate.

This logic suggests that it makes perfect sense to specify a high burst value (e.g. 100 and more) and a low rate value (even something like 2r/s). This handles normal browsing (a batch of parallel requests followed by a quiet period) better while protecting against sustained bot request stream.

0
2

I asked Nicolas's question to the guy who wrote the below post in nginx website. NGINX Rate limiting.His reply is as below

In the former rate limit, nginx will accept consecutive requests at 1/6th seconds intervals. it will not accept a burst of requests that do not satisfy that minimum time interval. On the other hand in the latter definition, nginx will accept a burst of up to 6 requests regardless of the time interval between requests. Answer link

1
  • Hello @Gardener and welcome on Server Fault. Thanks for your well crafted contribution. The link to source is very appreciated.
    – Marco
    Nov 6, 2019 at 10:56
1

Based on the excellent Dan's answer and on the source code of nginx, a concise summary for the nodelay behavior seems to be the following:

  • burst is how many new concurrent requests are allowed.
  • rate is how many new concurrent requests become old per unit of time. (This updating happens gradually: once per request but not per second.)
-2

I'm suggesting to read this thread: limit_req_zone limit by location/proxy

and this answer: stackoverflow

1
  • 1
    Link-only answers are considered sub-par on Server Fault. Please provide useful content here and then link elsewhere for more detail if needed.
    – EEAA
    May 4, 2016 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.