response-rate-limiting - "window" explained?
dot at dotat.at
Mon Jan 8 11:37:10 UTC 2018
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.
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.
More information about the bind-users