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?

ivanleoncz
  • 1,643
  • 6
  • 19
  • 32
Nicolas
  • 387
  • 2
  • 5
  • 12

6 Answers6

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.
Bernard Rosset
  • 1,373
  • 12
  • 25
  • 3
    Thanks for your clarification, the documentation isn't clear enough for me. – Nicolas Nov 11 '14 at 21:40
  • 1
    I edited my answer to reflect the documentation by quoting it. Every word is carefully weighted in nginx documentation to make it concise: that is what is nice about it. – Bernard Rosset Nov 12 '14 at 16:48
  • 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 '14 at 16:23
  • So you had not understood my answer... The first case will process 6 r/s (hopefully process them immediately), while the second case will accept 6 connections, but process them 1 r/s (so at least 6 seconds processing time total). The only difference between 1 r/s with and without `burst=5` is that without the queue, only the 1st connection will be accepted while the 5 others will be '503ed' – Bernard Rosset Nov 14 '14 at 00:02
  • Thanks for the additional explanations. It's a lot clearer to me now. – Nicolas Nov 16 '14 at 15:09
  • 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 '15 at 09:09
  • 2
    @BernardRosset could you please clarify the "queue won't be waiting" — what do you mean by that? – Denis Gorbachev Jul 25 '15 at 11:28
  • 3
    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. – Josh Ribakoff Sep 09 '17 at 17:47
  • So "nodelay" gives a trust burst, allowing requests to come in faster than the rate limit. A burst w/o "nodelay" isn't really a burst. It should have probably been named "queue length", not "burst". And "nodelay" should have probably been named "burst". – Josh Ribakoff Sep 09 '17 at 17:50
  • 1
    It all depends on how you interpret 'burst': On one hand, the docs are talking about burst of requests, referring to the non-linear fashion of requests in a Web environment, which might defeat you request limiting threshold (you define an average rate and then you use `burst` to accept deviations from a linear request rate while flattening it on the response end). On the other hand, you are referring to 'burst' as the immediate serving of requests, which is actually a special case handled for the occasion by the `nodelay` parameter – Bernard Rosset Jan 27 '18 at 23:40
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.

fsm
  • 97
  • 1
  • 1
  • Thanks to have clarified this point, which was effectively the reason of my question. – Nicolas Aug 01 '15 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. – Bernard Rosset Jan 30 '17 at 14:51
  • @BernardRosset: but with `nodelay`, won't that mean those requests are processed immediately instead of queued? – siride Jan 10 '18 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 '22 at 04: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.

Dan
  • 181
  • 2
  • 3
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

  • Hello @Gardener and welcome on Server Fault. Thanks for your well crafted contribution. The link to source is very appreciated. – Marco Nov 06 '19 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.)
Kirill Bulygin
  • 121
  • 3
-2

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

and this answer: stackoverflow

Community
  • 1
zoza
  • 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 04 '16 at 12:35