ratelimit_meter is deprecated & in maintenance-only mode
In late 2019, I realized that a bunch of design decisions I made in
ratelimit_meter (one of my first "real" rust projects) meant that
some bugs were ~forever baked in. To fix that, I re-wrote the core of
this library as
governor. It is more
fully-featured, more modern, less
and it has way less potential for buggy usage.
There is a migration guide available.
With the above in mind, please take the rest of this README with
several grains of salt (and use
governor if you can)!
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
Add the crate
ratelimit_meter to your
file; the crates.io page
can give you the exact thing to paste.
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
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!