Benchmark Snapshot — 2026-06-13 (beast, Linux SATA SSD)

Machine: beast — Intel Core i9-9900K (8c/16t) · 31 GiB · Linux 6.17.0 · ext4 on a Samsung SATA SSD (/dev/sdc2, fdatasync) Branch / commit: v1/phase-3-performance @ c46c0c7 (post-Phase-4: weir-ctl, weir-sink-sdk, full DST harness) Server config: shard_count=4, batch_size=64 (the load suite's bench_preset) Method: tests/load.rs, release build, 3 serial trials per deadline (--test-threads=1, averaged), at batch_deadline 1 ms and 2 ms. Rendered with deploy/avg_benchmarks.py.

The honest slow-storage reference. beast's SATA fdatasync (~1.5 ms, no power-loss-protected write cache) is the realistic durability floor — ~10× the Mac dev box's F_BARRIERFSYNC. Compare like-for-like (beast-to-beast for future runs). Cross-environment analysis: snapshot-2026-06-13-comparison.md.

TL;DR

  • The durable path is fsync-bound — and on honest storage it dominates everything. A single Sync record is 1.5 ms p50, of which ~99% is fdatasync. Single-thread Sync is just 653 RPS.
  • Batched is identical to Sync (1.5 ms p50) — same group-fsync code path.
  • Buffered (memory-only ack) is ~80× faster than Sync here — 19 µs p50, 49,725 RPS single-thread — because it never fsyncs. On this box the fast path actually beats the Mac.
  • Group-fsync amortization is the only thing that scales Sync: single-thread 653 RPS → ~6.8k RPS @ 96 threads as concurrent records coalesce under one fsync (~10× via batching), but the ~1.5 ms fsync floor caps it hard.
  • Buffered scales to ~155k RPS @ 48 threads (the connection cap).
  • No regression from the Phase 4 / DST work — these match the Phase 3 beast baseline (single-thread Sync 653 vs 647; Buffered ramp 155k vs 157k).

Throughput — deadline comparison

ScenarioRPS (1ms)±σ (1ms)RPS (2ms)±σ (2ms)d1ms/d2ms
single_thread_buffered49,725±3,75245,745±2,7271.09×
single_thread_sync653±19617±01.06×
thundering_herd_8_threads1,258±1621,255±2351.00×
thundering_herd_32_threads4,445±5074,367±9451.02×
thundering_herd_64_threads9,296±1,4168,264±1,5861.12×
connection_churn14,394±96714,916±390.96×
fire_and_forget_overload3,899±83,942±1440.99×

Latency — single thread, batch_deadline_ms=1

MetricSyncBatchedBuffered
Min1.1 ms1.1 ms16 µs
Mean1.6 ms1.6 ms19 µs
σ532 µs532 µs6 µs
p501.5 ms1.5 ms19 µs
p751.5 ms1.6 ms19 µs
p951.7 ms1.7 ms22 µs
p994.2 ms4.2 ms34 µs
p99.96.0 ms6.3 ms151 µs
Max7.2 ms7.0 ms188 µs

Latency — single thread, batch_deadline_ms=2

MetricSyncBatchedBuffered
Min1.2 ms1.2 ms16 µs
Mean1.6 ms1.6 ms18 µs
σ518 µs515 µs7 µs
p501.5 ms1.5 ms17 µs
p751.6 ms1.6 ms18 µs
p951.7 ms1.7 ms22 µs
p994.2 ms4.2 ms40 µs
p99.96.1 ms5.4 ms124 µs
Max6.8 ms5.5 ms279 µs

Saturation Ramp — Buffered tier

Server started with max_connections = 48. Levels above 48 trigger connection-cap exhaustion; the server must survive every level.

ThreadsRPS (d1ms)RPS (d2ms)I/O dropsStatus
830,86432,5790ok
1662,40165,1780ok
32116,550118,6610ok
48155,577157,0440ok
64149,343149,29316SATURATED ←
96151,028154,25548SATURATED

Saturation Ramp — Sync tier

Uses Sync durability to stress the group-fsync path under escalating concurrency. The ~1.5 ms fdatasync floor caps throughput an order of magnitude below the Mac.

ThreadsRPS (d1ms)RPS (d2ms)I/O dropsStatus
81,1991,0070ok
162,2821,9540ok
324,3994,1900ok
486,1785,3810ok
646,6185,78516SATURATED ←
966,8566,15548SATURATED

IOPS compression

249:1 — 4,980 records committed in 20 sink commits (content-derived, deterministic; identical to the Mac run).

Reproduce

Same as the Mac snapshot, run on beast (git checkout c46c0c7 first; cargo is under ~/.cargo/bin so . ~/.cargo/env in non-interactive shells):

. ~/.cargo/env; cd /root/weir
SNAP=/tmp/weir_beast.jsonl; : > "$SNAP"
for d in 1 2; do for i in 1 2 3; do
  WEIR_BENCH_DEADLINE=$d cargo test --release -p weir-server --test load -- \
    --nocapture --test-threads=1 2>/dev/null | grep -oE 'BENCH: \{[^}]*\}' >> "$SNAP"
done; done
python3 deploy/avg_benchmarks.py "$SNAP" /tmp/r.md && cat /tmp/r.md