Limit_req_zone and limit_req: rate too strict

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

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?

http://nginx.org/r/limit_req

limit_req zone=one burst=10 nodelay;

wbr, Valentin V. Bartenev

On Fri, 06 April 2012 “Valentin V. Bartenev” [email protected] 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

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

Module ngx_http_limit_req_module

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.

wbr, Valentin V. Bartenev