Setting limits that aren't per second
project707 opened this issue · comments
Despite the bursting issue being one of the problems you're solving here, is there a way to configure a limit based on requests per minute instead of second, but still using your rolling window for allowing requests again?
Per the documentation the throttle:<bursts>,<rate>,<timeout> defaults to throttle:60,1,1 which means 60 requests in a burst (e.g.: in 1 second) and a leak rate of 1 r/s which means that if you bursted all 60 requested in 1 second you'd only be able to make 1 r/s from then on. If you sat idle for 60 seconds then your quota would reset to 60 more. If you trip the burst quota you'll go into a 1 minute timeout which is to forcibly wait for the bucket to drain.
A value of throttle:60,60,10 would be 60 burst requests in a second with a leak of 60 r/s which means every second you can make another 60 but if you ever exceed 60 r/s then you'll go into a 10 minute timeout.
A value of throttle:10,0.0167,5 would correspond roughly to 10 burst requests within a minute as the 1 / 60 = 0.0167 leaks per second rate will leak 0.0167 request per second and takes 60s to leak 1 whole request. If you exceed therefore 10 requests in a minute then you'll go into a 5 minute timeout. Similarly throttle:60,0.1,5 would leak 1 request every 10 seconds as 1 request / 0.1 requests/second = 10 seconds.
Timeout is configured in minutes. Requests are configured as instantaneous burst. The leak rate is configured in seconds but a decimal value will allow some granularity over the request leaking per minute instead of per second. Note that accuracy is limited this way due to rounding errors with floating point math.
I welcome a PR for an improved syntax to configure by the minute. Alternatively consider making a custom resolver which will let you control everything about the leaky bucket configuration including being able to change the leaking unit of measurement to minutes, hours, days, etc if you wanted.
For anyone wondering what we ended up doing, we went with the latter suggestion and created a custom resolver that implements the ArtisanSdk\RateLimiter\Contracts\Resolver interface. It made a lot of sense to go that route since we also realized that we needed to customize the names of cache keys, and set unlimited rates for internal applications that call the same API.