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?
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 :-)
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.