Performance
The performance of each algorithm and storage backend combination differ in throughput. Below are the benchmarks for each combination with optional parameters to filter by.
Throughput (Requests/sec)
Methodology¶
Each benchmark run measures throughput for a single execution of the workload:
- For a given configuration the test issues
TOTAL_REQUESTS(1000) logical requests. - Concurrency is limited to
CONCURRENCY(100). - Fill levels are applied before timing by performing
target = int(limit * fill_level)check()calls to bring the bucket/window to the desired starting occupancy (e.g.0.0= empty,0.95= 95% full). - Timing is wall-clock measured around the full batch (elapsed seconds for all
TOTAL_REQUESTS), and throughput reported asTOTAL_REQUESTS / elapsed(requests per second).
Notes:
-
This page shows a single measured throughput datapoint per run/configuration.
-
The measured throughput includes scheduling and task-launch overhead (not only the storage/algorithm execution time), especially for the async implementation that enqueues many tasks then serializes execution via the semaphore.
-
Fill levels represent how full the bucket/window is before the test starts (0.0 → 0% = empty, 0.95 → 95% = nearly full).
-
Limit represents how many requests per minute.
-
All tests were run on the same hardware with no other significant load.