17 releases (8 stable)
5.0.0 | Sep 30, 2019 |
---|---|
4.1.1 | Mar 20, 2019 |
4.0.1 | Oct 26, 2018 |
3.0.0 | Oct 20, 2018 |
0.5.0 | Oct 9, 2017 |
#367 in Concurrency
185 downloads per month
Used in 5 crates
79KB
1K
SLoC
Rate-Limiting with leaky buckets in Rust
This crate implements two rate-limiting algorithms in Rust:
- a leaky bucket and
- a variation on the leaky bucket, the generic cell rate algorithm (GCRA) for rate-limiting and scheduling.
ratelimit_meter
is usable in no_std
mode, with a few trade-offs on
features.
Installation
Add the crate ratelimit_meter
to your Cargo.toml
file; the crates.io page
can give you the exact thing to paste.
API Docs
Find them on docs.rs for the latest version!
Design and implementation
Unlike some other token bucket algorithms, the GCRA one assumes that all units of work are of the same "weight", and so allows some optimizations which result in much more concise and fast code (it does not even use multiplication or division in the "hot" path for a single-cell decision).
All rate-limiting algorithm implementations in this crate are thread-safe. Here are some benchmarks for repeated decisions (run on my macbook pro, this will differ on your hardware, etc etc):
$ cargo bench
Finished release [optimized] target(s) in 0.16s
Running target/release/deps/ratelimit_meter-9874176533f7e1a0
running 1 test
test test_wait_time_from ... ignored
test result: ok. 0 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out
Running target/release/deps/criterion-67011381a5f6ed00
multi_threaded/20_threads/GCRA
time: [1.9664 us 2.0747 us 2.1503 us]
thrpt: [465.04 Kelem/s 482.00 Kelem/s 508.55 Kelem/s]
Found 10 outliers among 100 measurements (10.00%)
4 (4.00%) low severe
4 (4.00%) low mild
2 (2.00%) high mild
multi_threaded/20_threads/LeakyBucket
time: [2.4536 us 2.4878 us 2.5189 us]
thrpt: [396.99 Kelem/s 401.96 Kelem/s 407.56 Kelem/s]
Found 8 outliers among 100 measurements (8.00%)
5 (5.00%) low severe
3 (3.00%) low mild
single_threaded/1_element/GCRA
time: [68.613 ns 68.779 ns 68.959 ns]
thrpt: [14.501 Melem/s 14.539 Melem/s 14.575 Melem/s]
Found 13 outliers among 100 measurements (13.00%)
9 (9.00%) high mild
4 (4.00%) high severe
single_threaded/1_element/LeakyBucket
time: [64.513 ns 64.855 ns 65.272 ns]
thrpt: [15.321 Melem/s 15.419 Melem/s 15.501 Melem/s]
Found 16 outliers among 100 measurements (16.00%)
4 (4.00%) high mild
12 (12.00%) high severe
single_threaded/multi_element/GCRA
time: [96.461 ns 96.976 ns 97.578 ns]
thrpt: [102.48 Melem/s 103.12 Melem/s 103.67 Melem/s]
Found 11 outliers among 100 measurements (11.00%)
4 (4.00%) high mild
7 (7.00%) high severe
single_threaded/multi_element/LeakyBucket
time: [69.500 ns 70.359 ns 71.349 ns]
thrpt: [140.16 Melem/s 142.13 Melem/s 143.88 Melem/s]
Found 9 outliers among 100 measurements (9.00%)
6 (6.00%) high mild
3 (3.00%) high severe
no-op single-element decision
time: [23.755 ns 23.817 ns 23.883 ns]
Found 11 outliers among 100 measurements (11.00%)
5 (5.00%) high mild
6 (6.00%) high severe
no-op multi-element decision
time: [22.772 ns 22.940 ns 23.125 ns]
Found 5 outliers among 100 measurements (5.00%)
5 (5.00%) high mild
Contributions welcome!
I am actively hoping that this project gives people joy in using rate-limiting techniques. You can use these techniques for so many things (from throttling API requests to ensuring you don't spam people with emails about the same thing)!
So if you have any thoughts about the API design, the internals, or you want to implement other rate-limiting algotrithms, I would be thrilled to have your input. See CONTRIBUTING.md for details!
Dependencies
~16–530KB