# Possible to have a limit\_req "nodelay burst" option?

**URL:** <https://www.ruby-forum.com/t/possible-to-have-a-limit-req-nodelay-burst-option/228264>\
**Category:** NGINX\
**Created:** [April 16, 2013, 12:18am UTC](https://www.ruby-forum.com/t/possible-to-have-a-limit-req-nodelay-burst-option/228264 "2013-04-16T00:18:30Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![indigoi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/b3f665/32.png) [@indigoi](https://www.ruby-forum.com/u/indigoi)\
**Post date:** [April 16, 2013, 12:18am UTC](https://www.ruby-forum.com/t/possible-to-have-a-limit-req-nodelay-burst-option/228264/1 "2013-04-16T00:18:30Z")

</div>

Hello,  
I’m using the limit\_req directive to control the rate at which my  
backends  
are hit with requests. Typically a backend will generate a page and the  
client will not request anything for a short while, so a rate of 1 per  
second works well. Sometimes however a backend will return a HTTP  
redirect,  
and then the client must wait for a one second delay on the request to  
the  
redirected page. I’d like to avoid this if possible to avoid the slow  
feeling when users click on redirected links.

The nodelay option looked like it would work at first glance, but this  
bypasses the delay completely for all requests up to the burst, so it’s  
still possible for the backend to be hit with many requests at once.  
Ideally I would like to have a “nodelay burst” option to control how  
many  
of the burst requests are processed without delay which I could set to 2  
in  
my situation, while still delaying any further requests beyond that.

Another idea I had was to have the backend send a special header similar  
to  
how X-Accel-Redirect works, eg X-Limit-Req: 0 to avoid counting a single  
request towards the rate limit for purposes of redirects and similar  
situations.

Any other thoughts how something like this could work?

---

<div class="post-metadata">

**Author:** ![indigoi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/b3f665/32.png) [@indigoi](https://www.ruby-forum.com/u/indigoi)\
**Post date:** [April 16, 2013, 12:38am UTC](https://www.ruby-forum.com/t/possible-to-have-a-limit-req-nodelay-burst-option/228264/2 "2013-04-16T00:38:22Z")

</div>

Hello!

On Mon, Apr 15, 2013 at 06:18:04PM -0400, Richard S. wrote:

> bypasses the delay completely for all requests up to the burst, so it’s  
> still possible for the backend to be hit with many requests at once.  
> Ideally I would like to have a “nodelay burst” option to control how many  
> of the burst requests are processed without delay which I could set to 2 in  
> my situation, while still delaying any further requests beyond that.

… and next time you’ll notice that site feels slow on a page  
which uses 2 redirects in a row, or includes an image/css from a  
backend, or user just clicks links fast enough.

I would recommend just using “limit\_req … nodelay” unless you  
are really sure you need a delay in a particular case.

–  
Maxim D.

> **[nginx: donation](http://nginx.org/en/donation.html)**

---

<div class="post-metadata">

**Author:** ![indigoi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/b3f665/32.png) [@indigoi](https://www.ruby-forum.com/u/indigoi)\
**Post date:** [April 16, 2013, 2:09am UTC](https://www.ruby-forum.com/t/possible-to-have-a-limit-req-nodelay-burst-option/228264/3 "2013-04-16T02:09:31Z")

</div>

On Mon, Apr 15, 2013 at 6:38 PM, Maxim D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> > and then the client must wait for a one second delay on the request to the  
> > … and next time you’ll notice that site feels slow on a page  
> > which uses 2 redirects in a row, or includes an image/css from a  
> > backend, or user just clicks links fast enough.
> 
> I would recommend just using “limit\_req … nodelay” unless you  
> are really sure you need a delay in a particular case.

Thanks for the reply. I’ll try to explain my situation a little  
better, the delay is mainly there to prevent crazy scripts / spambots  
/ etc from making too many fast requests to the backend and tying up  
the “expensive” processes. Images and CSS are served from a separate  
backend that isn’t subject to rate limiting, and if the main backend  
determines a redirect is needed, it will guarantee a redirect to a  
final URL with no further intermediate redirects.

Currently I’m using a burst of 10 since showing a 503 to users is a  
bad experience, in the event they click links really fast I’d prefer  
them to just think the server is a little busy. I was hoping to remove  
this delay on redirects or at least the first couple of “fast clicks”,  
while still causing spambots / etc to be subjected to 1 req/s delay so  
the backend is not suddenly hit with up to 10 requests at once. For  
now I’m going to try using rewrite rules to catch the most commonly  
redirected paths and pass them to a non-limited backend, but I’d  
really like to see this feature if possible.

Regards,  
Richard

---

<div class="post-metadata">

**Author:** ![indigoi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/b3f665/32.png) [@indigoi](https://www.ruby-forum.com/u/indigoi)\
**Post date:** [June 17, 2014, 2:32am UTC](https://www.ruby-forum.com/t/possible-to-have-a-limit-req-nodelay-burst-option/228264/4 "2014-06-17T02:32:17Z")

</div>

+1 to the idea.

Maybe something like:  
limit\_req one burst=10 nodelay=5; # first 5 ‘bursts’ don’t have a delay,  
the  
next 5 do

I haven’t tried, but I suspect this doesn’t do the desired thing:  
limit\_req one burst=10;  
limit\_req one burst=5 nodelay;

(I’m guessing that the first directive above essentially overrides the  
second for the first 5, then the second directive overrides the first  
after  
that)

Posted at Nginx Forum:

> **[Re: Possible to have a limit\_req "nodelay burst" option?](https://forum.nginx.org/read.php?2,238389,250902#msg-250902)**
>
> Hello, I'm using the limit\_req directive to control the rate at which my backends are hit with requests. Typically a backend will generate a page and the client will not request anything for a short while, so a rate of 1 per second works well....

---

<div class="post-metadata">

**Author:** ![indigoi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/b3f665/32.png) [@indigoi](https://www.ruby-forum.com/u/indigoi)\
**Post date:** [October 15, 2014, 9:51am UTC](https://www.ruby-forum.com/t/possible-to-have-a-limit-req-nodelay-burst-option/228264/5 "2014-10-15T09:51:19Z")

</div>

ppy wrote in post #1114430:

> I have to agree with this completely. In fact, I thought this was the  
> intended behaviour of the “burst” argument, and it wasn’t until further  
> testing that I realised its true meaning.
> 
> I am looking for the exact same behaviour here – to allow _actual_ burst  
> requests before the delay starts to kick in. The eventual 503 is not  
> necessary.

I came across the same issue today. Actually, a lot of the explanations  
of the limit\_req functionality that you can find on the web seem to  
think that it works that way, probably because it would be the most  
intuitive and useful way to do it.

---

<div class="post-metadata">

**Author:** ![indigoi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/b3f665/32.png) [@indigoi](https://www.ruby-forum.com/u/indigoi)\
**Post date:** [February 5, 2016, 10:52am UTC](https://www.ruby-forum.com/t/possible-to-have-a-limit-req-nodelay-burst-option/228264/6 "2016-02-05T10:52:07Z")

</div>

I support this proposal. We need this functionality, too.

Posted at Nginx Forum:

> **[Re: Possible to have a limit\_req "nodelay burst" option?](https://forum.nginx.org/read.php?2,238389,264364#msg-264364)**
>
> Hello, I'm using the limit\_req directive to control the rate at which my backends are hit with requests. Typically a backend will generate a page and the client will not request anything for a short while, so a rate of 1 per second works well....

---

<div class="post-metadata">

**Author:** ![indigoi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/b3f665/32.png) [@indigoi](https://www.ruby-forum.com/u/indigoi)\
**Post date:** [July 4, 2013, 6:04pm UTC](https://www.ruby-forum.com/t/possible-to-have-a-limit-req-nodelay-burst-option/228264/7 "2013-07-04T18:04:49Z")

</div>

I have to agree with this completely. In fact, I thought this was the  
intended behaviour of the “burst” argument, and it wasn’t until further  
testing that I realised its true meaning.

I am looking for the exact same behaviour here – to allow _actual_ burst  
requests before the delay starts to kick in. The eventual 503 is not  
necessary. I believe this is a very common scenario and it would likely  
benefit a lot of others looking for the same kind of thing.

Posted at Nginx Forum:

> **[Re: Possible to have a limit\_req "nodelay burst" option?](https://forum.nginx.org/read.php?2,238389,240585#msg-240585)**
>
> Hello, I'm using the limit\_req directive to control the rate at which my backends are hit with requests. Typically a backend will generate a page and the client will not request anything for a short while, so a rate of 1 per second works well....
