Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow larger rate limits for extended time intervals #3594

Open
TheFreaky opened this issue Nov 13, 2024 · 0 comments · May be fixed by #3595
Open

Allow larger rate limits for extended time intervals #3594

TheFreaky opened this issue Nov 13, 2024 · 0 comments · May be fixed by #3595

Comments

@TheFreaky
Copy link

Is your feature request related to a problem? Please describe.
I'm experiencing limitations when setting up daily rate limits with Spring Gateway's Redis Rate Limiter. According to the documentation:

Rate limits below 1 request/s are accomplished by setting replenishRate to the wanted number of requests, requestedTokens to the timespan in seconds, and burstCapacity to the product of replenishRate and requestedTokens.

For instance, replenishRate=1, requestedTokens=86400 (for a full day in seconds), and burstCapacity=86400 would theoretically enable a 1 request/day rate limit.

However, in the current implementation, burstCapacity is limited to the maximum int value. This means that for a daily rate limit, we can't specify more than 2147483647 / 86400 ≈ 25,000 requests. This constraint makes it challenging to set higher daily limits, which are often required for applications with high usage.

Describe the solution you'd like
I would like burstCapacity to be stored as a long instead of an int. Since burstCapacity does not involve multiplication in the rate-limiting Lua script logic, switching to long should not introduce any risks (such as overflow) but would allow for larger rate limits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant