Tom <[email protected]> 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 <[email protected]> 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. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
