You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I have the same issue with this #1876
I see rate limiting as an important feature that should be implemented as a separate function instead of using a shared function (SetRollingWindow, GetRollingWindow) with other functionalities, which can result in resource waste
Describe the solution you'd like
After researching, I have decided to optimize the rate limit feature by using a Lua script for Redis. For more details, please refer to the pull request #5921
Additional context
I have built a sample API to compare the rate limit before and after the improvement. With a per value of 300, rate value of 60, and a server firing a load with 5 worker pools and 20k requests:
With the original rate limit, it takes 60 seconds to complete. The CPU usage increases by 60%, and the sorted set reaches 2MB with nearly 20k keys.
With the improved rate limit, it only takes 6 seconds to complete. The CPU usage peaks at 6%, and the sorted set size is reduced to 1KB with 60 keys.
The text was updated successfully, but these errors were encountered:
@cuongtd1301 hello, i've closed your PR with more detail; If you use the recently available fixed window rate limiter, you should be in the best case performance bracket, as it only needs to maintain a couple of redis keys. Note that it doesn't currently support spike arrest, so the expected behaviour is to block any overflow of rate for the remainder of per (rate limit window duration).
I'm leaving the issue open in case you'd want to rerun any tests or provide additional feedback. The sliding log behaviour is known to be inefficent, however, code structure since you've filed the issue has changed significantly, and fixed window rate limiting is available, as well as a sliding window rate limiter if you build your own gateway as it's currently only available when built with a dev tag; sliding window most matches sliding log by having spike arrest behaviour while having fixed resource usage on redis side.
Is your feature request related to a problem? Please describe.
I have the same issue with this #1876
I see rate limiting as an important feature that should be implemented as a separate function instead of using a shared function (SetRollingWindow, GetRollingWindow) with other functionalities, which can result in resource waste
Describe the solution you'd like
After researching, I have decided to optimize the rate limit feature by using a Lua script for Redis. For more details, please refer to the pull request #5921
Additional context
I have built a sample API to compare the rate limit before and after the improvement. With a per value of 300, rate value of 60, and a server firing a load with 5 worker pools and 20k requests:
With the original rate limit, it takes 60 seconds to complete. The CPU usage increases by 60%, and the sorted set reaches 2MB with nearly 20k keys.
With the improved rate limit, it only takes 6 seconds to complete. The CPU usage peaks at 6%, and the sorted set size is reduced to 1KB with 60 keys.
The text was updated successfully, but these errors were encountered: