Lightbench
A lightweight load testing framework for measuring latency, throughput, and reliability of external systems under sustained, rate-controlled load.
Load testing vs micro-benchmarking: Lightbench is designed to drive load against external systems (HTTP services, message queues, async job APIs) — not to measure isolated code execution times. For micro-benchmarking Rust code, use Criterion.
Motivation
Built for academic research. Most load testers are great for DevOps — graphical UIs, rich dashboards, lots of bells and whistles — but they get in the way when you just need clean, reproducible numbers for a paper. The scriptable ones tend to be heavy enough that you start wondering how much of your measured latency is actually the tester's fault.
Rust fixes that. The overhead is tiny and predictable — no GC, no interpreter — so you can trust your numbers. And since a single Rust process can push very high request rates, you don't need a distributed load generation cluster just to stress-test one box.
Features
- Three Load Test Patterns: Request, Producer/Consumer, and Async Task (submit + poll)
- Load Test Runner: High-level builder with automatic rate distribution across workers
- Rate Control: Per-worker token bucket (
RateController) and shared lock-free pool (SharedRateController) - CSV Export: Write snapshots to file with
.csv(path)option - Progress Display: User-friendly live progress or raw CSV output
- HDR Histogram Metrics: High-precision latency tracking with percentile reporting (p25, p50, p75, p95, p99)
- Sequence Tracking: Duplicate and gap detection for reliability measurement
- Error Bucketing:
ErrorCountergroups errors by reason string for summary reporting
Quick Start
Add to your Cargo.toml:
[]
= "0.3"
= { = "1", = ["full"] }
To enable CLI argument parsing via clap, add the clap feature:
[]
= { = "0.3", = ["clap"] }
= { = "1", = ["full"] }
= { = "4", = ["derive"] }
Feature Flags
| Feature | Default | Description |
|---|---|---|
clap |
off | Derives clap::Parser on BenchmarkConfig, enabling direct CLI parsing with BenchmarkConfig::parse(). |
clap Feature
When the clap feature is enabled, BenchmarkConfig derives clap::Parser and exposes all benchmark options (--rate, --workers, --duration, etc.) as CLI flags. You can either use it as a standalone parser or flatten it into a larger clap struct.
Standalone parser — simplest case, all options come from the command line:
use Parser;
use ;
;
async
Run it:
Embedded with #[command(flatten)] — add your own flags alongside the benchmark options:
use Parser;
use ;
async
Available CLI flags (all optional, with defaults):
| Flag | Short | Default | Description |
|---|---|---|---|
--rate |
-r |
unlimited | Total req/s shared across workers (<=0 = unlimited) |
--rate-per-worker |
-R |
— | Req/s per worker (ignored when --rate is set) |
--workers |
-w |
1 |
Number of worker tasks |
--duration |
-d |
5 |
Test duration in seconds |
--ramp-up |
-u |
— | Ramp-up duration in seconds before the measured phase |
--ramp-start |
— | 0 |
Initial rate at the start of ramp-up |
--burst-factor |
— | 0.1 |
Burst allowance in seconds-worth of tokens |
--csv |
— | — | Write snapshots to a CSV file at this path |
--no-progress |
— | off | Disable live progress; write raw CSV rows to stdout |
--hide-ramp-progress |
— | off | Hide progress output during ramp-up |
--drain-timeout |
— | 30 |
Seconds to wait for in-flight items after duration |
Request Pattern (Request/Response)
use ;
async
Worker lifecycle: init() is called once per worker to create State. Put shared,
Clone-friendly resources (URLs, config, Arc<Pool>) in the struct. Put resources that
must not be shared across workers (HTTP clients, dedicated connections) in State.
Rate Modes:
.rate(1000.0)— Shared rate pool (workers compete for 1000 total req/s).rate_per_worker(250.0)— Each worker gets 250 req/s independently.rate(0.0)or.rate(-1.0)— Unlimited (maximum throughput)
Producer/Consumer Pattern
use ;
use VecDeque;
use Arc;
use Mutex;
type Queue = ;
async
Trait contracts:
- ProducerWork::produce: returns
Ok(())on success orErr(reason)on failure. Rate-controlled by the framework. - ConsumerWork::run: consumer owns its event loop. Returns
Self::Statewhen done (passed tocleanup). Userecorder.record(latency_ns)to report each consumed item.recorder.is_running()— poll-style check, suitable for tight loops.recorder.stopped().await— async signal, use intokio::select!to unblock a pending receive when the benchmark ends.
- ConsumerWork::cleanup (optional): called with the
Statereturned byrun— close subscriptions, connections, etc. Default: no-op.
Stopping a blocked consumer — when the consumer is awaiting a message from a channel or subscription, is_running() will never be checked. Use stopped() instead:
async
Async Task Pattern (Submit + Poll)
use ;
async
Examples
Noop (framework overhead baseline)
Options: --rate <N>, --rate-per-worker <N>, --workers <N>, --duration <S>, --csv <FILE>, --no-progress
HTTP GET Benchmark
Options:
--rate <N>— Total requests/sec (shared pool, use<=0for unlimited)--rate-per-worker <N>— Requests/sec per worker (independent limiters)--duration <S>— Test duration in seconds (default: 10)--workers <N>— Worker count (default: 4)--csv <FILE>— Write snapshots to CSV--no-progress— Disable progress display, output CSV rows to stdout
Producer/Consumer Benchmark
Options: --producers <N>, --consumers <N>, --rate <N>, --duration <S>, --csv <FILE>, --no-progress
Async Task Benchmark
Options: --submit-workers <N>, --poll-workers <N>, --rate <N>, --duration <S>, --processing-delay <MS>, --csv <FILE>, --no-progress
Modules
patterns
Three load test patterns, each a builder plus results type.
Benchmark (request pattern):
use ;
let results = new
.rate // Shared rate pool (not split per-worker)
.workers // Workers compete for tokens
.duration_secs
.work
.run
.await;
results.print_summary; // Formatted output
println!;
println!;
ProducerConsumerBenchmark:
.producer(impl ProducerWork)— rate-controlled,produce()returnsOk(())orErr(reason).consumer(impl ConsumerWork)— consumer owns its event loop viarun(state, recorder) -> State, reports items withrecorder.record(latency_ns). Stop viarecorder.is_running()(polling) orrecorder.stopped().await(tokio::select!). Optionalcleanup(state)hook runs afterrunreturns.
AsyncTaskBenchmark:
.submit(fn)— rate-controlled, returnsSome(task_id: u64)orNone.poll(fn)— free-running, returnsPollResult::{Completed{latency_ns}, Pending, Error(reason)}
metrics
Statistics collection with HDR histogram for latency tracking.
use Stats;
let stats = new;
stats.record_sent.await;
stats.record_received.await;
stats.record_received_batch.await; // Efficient batch
let snapshot = stats.snapshot.await;
println!;
println!;
SequenceTracker — per-consumer duplicate/gap detection:
use SequenceTracker;
let mut tracker = new;
tracker.record; // returns false if duplicate
tracker.duplicate_count;
tracker.gap_count; // gaps within min..=max range
tracker.head_loss; // min_seq (sequences lost before first received)
ErrorCounter — thread-safe error bucketing:
use ErrorCounter;
let counter = new;
counter.record.await;
counter.record.await;
let errors = counter.take.await; // HashMap<String, u64>
print_summary;
rate
Token bucket rate limiters for controlled benchmarks.
RateController — per-worker:
use RateController;
let mut rate = new; // 1000 msg/s for this worker
loop
SharedRateController — lock-free, shared across workers:
use SharedRateController;
use Arc;
let rate = new; // 1000 msg/s total
for _ in 0..4
time_sync
Fast timestamp utilities avoiding syscall overhead.
use ;
let start = now_unix_ns_estimate;
// ... do work ...
let elapsed = latency_ns;
logging
Tracing initialization:
use logging;
init.ok; // env-filter string
init_default.ok; // info level
output
Async CSV and stdout writers:
use OutputWriter;
let mut writer = new_csv.await?;
writer.write_snapshot.await?;
writer.flush.await?;
CSV Output Format
Snapshots are written as 19-column CSV rows:
timestamp,sent_count,received_count,error_count,total_throughput,interval_throughput,
latency_ns_p25,latency_ns_p50,latency_ns_p75,latency_ns_p95,latency_ns_p99,
latency_ns_min,latency_ns_max,latency_ns_mean,latency_ns_stddev,latency_sample_count,
duplicate_count,gap_count,head_loss
Quality columns (duplicate_count, gap_count, head_loss) are 0 unless a
SequenceTracker is in use.