cmc333333
commented
9 years ago Some tests:
| Window Size (s) | Bucket Size (s) | # Buckets | Total hits | hits/s | KB/s |
|---|---|---|---|---|---|
| 3600 | 3600 | 1 | 18671 | 622 | 379 |
| 3600 | 60 | 60 | 17344 | 578 | 352 |
| 3600 | 10 | 360 | 8838 | 295 | 169 |
| 3600 | 1 | 3600 | 1615 | 56 | 33 |
| 3600 | 0.1 | 36000 | 60 | 2 | 1 |
| 3600000 | 100 | 36000 | 0 | 0 | 0 |
| 3600000 | 1000 | 3600 | 150 | 5 | 3 |
| 3600000 | 10000 | 360 | 7608 | 254 | 154 |
| 3600000 | 60000 | 60 | 19130 | 637 | 388 |
| 3600000 | 3600000 | 1 | 20583 | 686 | 417 |
In practice, we have at most 60 buckets per time frame, so I think we can close this
GUI
The rate limiting implementation in the lua branch is compatible with our current implementation that uses sliding windows. The primary differences is that it's using openresty shdicts, rather than redis to store the information locally. If a bucket is setup with a long duration and high accuracy, I think the performance of this may degrade, since there's no way to bulk-fetch a bunch of shdict keys in openresty (other than looping, and fetching them one at a time). I think these high accuracy buckets may perform worse than our previous implementation. We need to investigate more.
There are potentially some different ways to handle the sliding time window buckets that might be more efficient with less fetches during query time (and shift those to a cleanup phase that keeps a single bucket up to date). Longer-term, there's also some potentially better/simpler ways to go about this if we split rate limits and quotas up (with rate limits using a leaky bucket algorithm, and quotas using a simpler non-sliding window). But for the initial release, I think it will be simpler if we can aim for the initial lua release to be a drop-in replacement for our current algorithms.