mirror of
https://github.com/neondatabase/neon.git
synced 2026-01-16 09:52:54 +00:00
a644f01b6a
In proxy I switched to a leaky-bucket impl using the GCRA algorithm. I
figured I could share the code with pageserver and remove the
leaky_bucket crate dependency with some very basic tokio timers and
queues for fairness.
The underlying algorithm should be fairly clear how it works from the
comments I have left in the code.
---
In benchmarking pageserver, @problame found that the new implementation
fixes a getpage throughput discontinuity in pageserver under the
`pagebench get-page-latest-lsn` benchmark with the clickbench dataset
(`test_perf_olap.py`).
The discontinuity is that for any of `--num-clients={2,3,4}`, getpage
throughput remains 10k.
With `--num-clients=5` and greater, getpage throughput then jumps to the
configured 20k rate limit.
With the changes in this PR, the discontinuity is gone, and we scale
throughput linearly to `--num-clients` until the configured rate limit.
More context in
https://github.com/neondatabase/cloud/issues/16886#issuecomment-2315257641.
closes https://github.com/neondatabase/cloud/issues/16886
---------
Co-authored-by: Joonas Koivunen <joonas@neon.tech>
Co-authored-by: Christian Schwarz <christian@neon.tech>
15 lines
433 B
Rust
15 lines
433 B
Rust
mod leaky_bucket;
|
|
mod limit_algorithm;
|
|
mod limiter;
|
|
|
|
#[cfg(test)]
|
|
pub(crate) use limit_algorithm::aimd::Aimd;
|
|
|
|
pub(crate) use limit_algorithm::{
|
|
DynamicLimiter, Outcome, RateLimitAlgorithm, RateLimiterConfig, Token,
|
|
};
|
|
pub(crate) use limiter::GlobalRateLimiter;
|
|
|
|
pub use leaky_bucket::{EndpointRateLimiter, LeakyBucketConfig, LeakyBucketRateLimiter};
|
|
pub use limiter::{BucketRateLimiter, RateBucketInfo, WakeComputeRateLimiter};
|