-
Notifications
You must be signed in to change notification settings - Fork 5
Rate Limit
Controls the rate of the operations by specifying a maximum amount of executions within a given time window.
// Create a new bot policy
var policy = new BotPolicy();
// Or with a return value
var policy = new BotPolicy<HttpResponseMessage>();
// Configure the policy to use rate limit on operations
policy.Configure(policyConfig => policyConfig
.RateLimit(rateLimitConfig => rateLimitConfig
.SlidingWindow( // Set the rate limiter strategy
5, // Set the amount of maximum allowed operations within the given time interval.
TimeSpan.FromSeconds(10) // Set the time interval within only the given maximum amount of operations are allowed.
)));
-
.SlidingWindow(int, TimeSpan)
- Sets the underlying strategy to a sliding window rate limiter.-
int
: The maximum allowed operation count within the given time interval. -
TimeSpan
: The time interval within only the given maximum amount of operations are allowed.
-
-
.FixedWindow(int, TimeSpan)
- Sets the underlying strategy to a fixed time window rate limiter.-
int
: The maximum allowed operation count within the given time interval. -
TimeSpan
: The time interval within only the given maximum amount of operations are allowed.
-
-
.UseStrategy(IRateLimiterStrategy)
- Sets the underlying strategy to a custom rate limiter.
The functionality of the Rate Limiter bot can be customized with a IRateLimiterStrategy
implementation. It can gives you more control over the internal behavior by determining when should the rate of the executions limited.
public class CustomStrategy : IRateLimiterStrategy
{
public bool ShouldLimit(out TimeSpan retryAfter)
{
// You can decide here that you allow the current operation or not.
}
}
Then you can use your custom strategy by configuring the Botpolicy
like this:
policy.Configure(policyConfig => policyConfig
.RateLimit(rateLimitConfig => rateLimitConfig
.UseStrategy(new CustomStrategy())));
-
Fixed window: It counts the number of operations within a fix time window and resets the counters at constant points in time.
Let's check an example where a configuration allows 2 requests within a given time window:^ <- this sign means that an operation is executed on the timeline |=============|=============|=============| ^ ^ ^ | <- the next point in time an operation allowed to execute |-------------| <- the fix sized window
However that should be kept in mind that this strategy allows "bursts" to be formed:
|=============|=============|=============| ^ ^ ^ ^ |---| <- 3 quick calls in a much less time window that we wanted to allow
You should use the Sliding Window strategy if you want to avoid these bursts.
-
Sliding window (used by default): Checks the relative time window related to the current request.
The same example (2 requests allowed) with this strategy would look like this:|=============|=============|=============| ^ ^ ^ | <- the next point in time an operation allowed to execute |-------------| <- the sliding window
When the configured rate limit is exceeded, the framework throws a custom
RateLimitExceededException
exception. From itsRetryAfter
property you can read the remaining time - as aTimeSpan
- left until the limiter allows the next execution.