# Limit\_req\_zone and limit\_req: rate too strict

**URL:** <https://www.ruby-forum.com/t/limit-req-zone-and-limit-req-rate-too-strict/218637>\
**Category:** NGINX\
**Created:** [April 6, 2012, 3:25pm UTC](https://www.ruby-forum.com/t/limit-req-zone-and-limit-req-rate-too-strict/218637 "2012-04-06T15:25:41Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [April 6, 2012, 3:25pm UTC](https://www.ruby-forum.com/t/limit-req-zone-and-limit-req-rate-too-strict/218637/1 "2012-04-06T15:25:41Z")

</div>

Hi,

I have started using limit\_req\_zone + limit\_req but am seeing more  
delayed  
log entries than I would expect.

I have the following:

limit\_req\_zone $binary\_remote\_addr zone=one:10m rate=3r/s;  
…  
server {  
…  
location ~ .\*.php$ {  
limit\_req zone=one burst=10;  
…  
}

In the logs I see that when 2 requests happen near simultaneously from  
the  
same IP address (e.g. page redirect to second PHP page or single  
PHP-generated image referenced by page) the second and third request get  
delayed if they arrive too early during the same second.

I would wish to limit the user to 3 requests within a 1s window though  
not setting any constraint as to spacing between those requests, how can  
I  
accomplish it or what changes to limit\_req module would be needed to  
not have a minimum 0.33s spacing between requests for above  
configuration?

Thanks,  
Bruno

---

<div class="post-metadata">

**Author:** ![SSBruno\_PrSSmontSS\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b4bc9f/32.png) [@SSBruno\_PrSSmontSS\_S](https://www.ruby-forum.com/u/SSBruno_PrSSmontSS_S)\
**Post date:** [April 6, 2012, 6:07pm UTC](https://www.ruby-forum.com/t/limit-req-zone-and-limit-req-rate-too-strict/218637/2 "2012-04-06T18:07:35Z")

</div>

On Friday 06 April 2012 17:24:52 Bruno Prmont wrote:

> ```
> ...
> 
> ```
> 
> I would wish to limit the user to 3 requests within a 1s window though  
> not setting any constraint as to spacing between those requests, how can I  
> accomplish it or what changes to limit\_req module would be needed to  
> not have a minimum 0.33s spacing between requests for above configuration?

> **[Module ngx\_http\_limit\_req\_module](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req)**
>
> The ngx\_http\_limit\_req\_module module (0.7.21) is used to limit the request processing rate per a defined key, in particular, the processing rate of requests coming from a single IP address. The limitation is done using the “leaky bucket” method.

```
limit_req zone=one burst=10 nodelay;

```

wbr, Valentin V. Bartenev

---

<div class="post-metadata">

**Author:** ![SSBruno\_PrSSmontSS\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b4bc9f/32.png) [@SSBruno\_PrSSmontSS\_S](https://www.ruby-forum.com/u/SSBruno_PrSSmontSS_S)\
**Post date:** [April 6, 2012, 9:39pm UTC](https://www.ruby-forum.com/t/limit-req-zone-and-limit-req-rate-too-strict/218637/3 "2012-04-06T21:39:42Z")

</div>

On Fri, 06 April 2012 “Valentin V. Bartenev” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> > server {  
> > delayed if they arrive too early during the same second.  
> > limit\_req zone=one burst=10 nodelay;  
> > In that case legitimate (from my point of view) requests get rejected  
> > which is even worse!

I wish those that fall under rate to not be delayed to get nice  
distribution  
(in my case 1s sample-rate!), but to have those between rate and burst  
being  
delayed to the following seconds.

As an example of what I expect (rate=3r/s, burst=5):  
Time Request Id  
0.0s 1 initial request  
0.1s 2 second request, should not get delayed  
0.1s 3 third request, should not get delayed  
3.5s 4 new initial request  
3.6s 5 new second request, should not get delayed  
3.7s 6 new third request, should not get delayed  
3.8s 7 new fourth request, should get delayed until  
t=4.6s  
3.9s 8 new fifth request, should get delayed until  
t=4.7s  
4.0s 9 new sixth request, should get delayed until  
t=4.8s  
4.1s 10 new seventh request, should get delayed until  
t=5.6s  
4.2s 11 new eighth request, should get delayed until  
t=5.7s  
4.3s 12 new ninth request, should get rejected with 503  
(exceeds burst)  
4.4s 13 new tenth request, should get rejected with 503  
(exceeds burst)

but I do get like:  
0.0s 1 initial request  
0.1s 2 second request, delayed until 0.33s  
0.1s 3 third request, delayed until 0.66s

Bruno

---

<div class="post-metadata">

**Author:** ![SSBruno\_PrSSmontSS\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b4bc9f/32.png) [@SSBruno\_PrSSmontSS\_S](https://www.ruby-forum.com/u/SSBruno_PrSSmontSS_S)\
**Post date:** [April 6, 2012, 10:57pm UTC](https://www.ruby-forum.com/t/limit-req-zone-and-limit-req-rate-too-strict/218637/4 "2012-04-06T22:57:05Z")

</div>

On Friday 06 April 2012 23:38:59 Bruno Prémont wrote:

> > [Module ngx\_http\_limit\_req\_module](http://nginx.org/r/limit_req)
> > 
> > ```
> > limit_req zone=one burst=10 nodelay;
> > 
> > ```
> 
> In that case legitimate (from my point of view) requests get rejected  
> which is even worse!

No, with “nodelay” parameter they won’t be rejected or delayed until the  
overflow of burst.

> I wish those that fall under rate to not be delayed to get nice  
> distribution (in my case 1s sample-rate!), but to have those between rate  
> and burst being delayed to the following seconds.  
> […]

There’s no discrete “sample-rate”. The limit\_req module implements  
classical  
“leaky bucket” algorithm, which is simple, cheap and very common in the  
telecom  
world.

> **[Leaky bucket](https://en.wikipedia.org/wiki/Leaky_bucket)**
>
> The leaky bucket is an algorithm based on an analogy of how a bucket with a constant leak will overflow if either the average rate at which water is poured in exceeds the rate at which the bucket leaks or if more water than the capacity of the bucket is poured in all at once. It can be used to determine whether some sequence of discrete events conforms to defined limits on their average and peak rates or frequencies, e.g. to limit the actions associated with these events to these rates or delay ...

wbr, Valentin V. Bartenev
