governor - a library for regulating the flow of data
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.
Implementation and constraints
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
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
This project is a fork/rebranding/continuation of
based on a few key insights and advancements in the ecosystem:
- The 2018 edition is now both available and extremely useful.
- Futures and
ratelimit_meterwas 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
in about 80 lines. The equivalent functionality with
takes about three lines in this crate.
No more two algorithms that do the same
ratelimit_meter shipped "two" algorithm classes,
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
So, why make a new crate?
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.