response-rate-limiting - "window" explained?

[Tony Finch]

Tom <tomtux007 at gmail.com> wrote:

> Mmmh...I can't verify the meaning of the "window"-value. In my flood-tests, it
> makes no differences, if I set this value to 5 or 60 or even 3600.

You'll only notice the window if you pause your flood test - it's
basically the recovery time. (This is why the "stop limiting" log message
is misleading: RRL actually stops limiting after the window passes, but it
logs 60s later.)

The relevant part of the ARM is:

> Response rate limiting uses a "credit" or "token bucket" scheme.  Each
> combination of identical response and client has a conceptual account
> that earns a specified number of credits every second. A prospective
> response debits its account by one. Responses are dropped or truncated
> while the account is negative.  Responses are tracked within a rolling
> window of time which defaults to 15 seconds, but can be configured with
> the window option to any value from 1 to 3600 seconds (1 hour).  The
> account cannot become more positive than the per-second limit or more
> negative than window times the per-second limit.  When the specified
> number of credits for a class of responses is set to 0, those responses
> are not rate limited.

So, during your flood test, your client's token bucket will have its
minimym value, -1 * window * responses-per-second. When it stops, the
token bucket value will increase by `responses-per-second` each second, so
it will increase past zero after `window` seconds, and at that point RRL
will stop dropping responses.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Rockall: South 6 to gale 8, backing southeast 7 to severe gale 9, perhaps
storm 10 later. Very rough or high. Occasional rain. Good, occasionally poor.