This library is an implementation of the Generic Cell Rate Algorithm for rate limiting in Rust programs.
It is intended to help your program know how much strain it is supposed to put on external services (and, to some extent, to allow your services to regulate how much strain they take on from their users). In a way, it functions like the iconic steam governor from which this library takes its name:
-
tide-governor: A tide middleware that provides rate-limiting functionality backed by governor.
-
actix-governor: A middleware for actix-web that provides rate-limiting backed by governor.
The rate-limiting algorithms in this crate are implemented using the Generic Cell Rate Algorithm (GCRA). The GCRA is functionally equivalent to a leaky bucket, but has a few advantages over most leaky bucket implementations:
- No background "drip" process is necessary to keep up maintenance on the bucket,
- it updates its state, whenever a request comes in, continuously on a nanosecond scale, and
- it keeps its state in a single
AtomicU64
integer.
The rate-limiting state used here does not take up much memory (only
64 bits!) and is updated thread-safely with a compare-and-swap
operation. Compared to ratelimit_meter
's implementation using
Mutexes, it is on average 10x faster when used on multiple threads.
The speed comes at a slight cost: Each rate-limiter and its state is only useful for 584 years after creation. If you are trying to power the Long Now Foundation's computers with this library, please get in touch.
How does this relate to ratelimit_meter
?
This project is a fork/rebranding/continuation of ratelimit_futures
,
based on a few key insights and advancements in the ecosystem:
- The 2018 edition is now both available and extremely useful.
- Futures and
async
/await
are stable. ratelimit_meter
was too generic for its own good, implementing two suboptimal variants of the same rate-limiting algorithm.
Let's go through these in order:
The code in this crate targets Rust's 2018 edition. This has allowed making the code less complicated and more idiomatic.
Before Rust 1.39, the only way to use Futures in stable was to make
combinators or poll them manually. There is a crate for
ratelimit_meter
that implements a rate-limiting
future
in about 80 lines. The equivalent functionality with async
/await
takes about three lines in this crate.
ratelimit_meter
shipped "two" algorithm classes, LeakyBucket
and
GCRA
. These behaved exactly the same (modulo a glitch where the
first cell in a GCRA was free), forcing every user to make a decision
that ultimately meant nothing.
This crate implements only the GCRA algorithm (minus the "first cell
is free" glitch) and does so in a more optimal way than
ratelimit_meter
could have.
The return values here are mostly concrete types, and the only type
parameter most things accept is the clock implementation, in order to
compile on no_std
.
There are a few reasons, but mostly these: One, I was unhappy with the name, which I found to not fit very well anymore; and two, I felt such a radically new interface would be burdensome on users in addition to being hard to implement incrementally in the old repo. These reasons may not be very good, but here we are.