6

We've decided that we want to experiment and limit requests per minute instead of requests per second on our sites. However, I am confused by the burst parameter in this context.

I am under the impression that when you use the 'nodelay' flag, the rate limiting facility acts like a token bucket instead of a leaky bucket. That being the case, the bucket size is equal to the burst parameter, and every time that you violate the policy (say 1 req/s), you have to put a token in the bucket. Once the bucket is full (being equal to the burst setting), you are given a 503 error page.

I am also under the impression that once a violator stops going against the policy, a token is removed from the bucket at a rate of 1 token/s allowing him to regain access to the site.

Assuming that I have the above correct, my question is what happens when I start regulating access per minute? If we chose 60 requests per minute, at what rate does the token bucket replenish?

1
  • While I don't intend to discourage discussion here, this technical question about nginx may obtain a more informed response by posting it to the nginx user's mailing list.
    – Jason
    May 29, 2010 at 20:02

2 Answers 2

5

From my experiments it seems that per minutes is just a way to write rates that are on sub-second intervals. So 60r/m == 1r/s. This can be demonstrated by setting it to 60 requests per minute and then launching say 2 requests per second. It will be limited from the start, not only after 60 requests have been made.

That being said, I still don't fully understand how this all works :-)

0

Yes, it does work like a token bucket algorithm. I also manually experimented with my server to verify this. You can see https://stackoverflow.com/questions/14869390/nginxngx-http-limit-req-module-for-how-long-is-503-returned-once-exceeding-the for example

If you choose 60 req/min it will replenish one token every second.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .