Benchmarks

Measured on garret itself, against a throwaway local Garage standing in for the object store. The numbers describe the cache, not the bucket.

What is measured

• Push: 20 concurrent pushers over a seeded corpus of 200 entries totalling 638 MiB, each entry 4 KiB to 16 MiB.
• Stream: single-stream pushes of 1 MiB, 100 MiB and 2 GiB bodies.
• Pull: 1200 concurrent narinfo and redirect requests.

The corpus is generated from a seed, so a run is reproducible without holding real store contents.

Systems

The Ryzen server limits apply to the garret services only: taskset -c 0 for the CPU pin, and per-service systemd user scopes with MemoryMax=896M MemorySwapMax=0 for the memory cap. Garage and the bench client stand in for out-of-sandbox components — the upstream S3 service and the pushing machines — and run unconstrained.

Results

The Pusher runs the default limits — a 256 MiB in-flight cap, 16 MiB parts, 4 parts in flight — except max_concurrent_uploads, raised from the default 16 to 32 so the 20 pushers are not shed.

Pass criteria

A run passes when it has zero failed requests and zero shed retries. The memory criterion is that peak Pusher RSS stays below twice the 256 MiB in-flight cap, that is 512 MiB. It held in every configuration above.

just bench-local enforces the peak. Final RSS is recorded in the JSON for comparison and is not gated.

Run-to-run variance

A second pass on the Mac agreed within 2% on push, the 1 MiB and 100 MiB streams, pull and RSS; the 2 GiB stream came in 5% higher and push p99 8% higher. On the Ryzen server, a second pass of the matrix agreed within 9% on push, streams and RSS, but not on pull: the 1200-request scenario lasts about 30 ms on 8 cores, and the two unpinned configurations came in 26–29% lower on the second pass, while the 1-CPU configurations agreed within 1%.

Treat the unpinned Ryzen pull column as indicative only. For pull comparisons, run GARRET_BENCH_ARGS="--passes 100 --no-giant" just bench-local for 40,000 requests. Most such runs agree within about 2%, but about one in five came in 4–18% low, so compare the best of three.

Why max is reported

Roughly half of the 1-CPU push runs catch a Garage artifact: a single push held open for seconds — occasionally forever, with megabytes unread in Garage’s socket receive queue — while every percentile stays normal, because with 200 entries p99 is only the second-worst sample. It reproduces with Garage unpinned on free cores and on tmpfs, with zero TCP retransmits and zero client retries, so it is a stand-in artifact rather than garret behaviour.

max_ms is the tell. A run whose max_ms is out of line with p99_ms, or whose wall time is far above the sum of latencies divided by concurrency, caught the stall and should be re-run rather than checked in.

Reproducing

just bench-local provisions a throwaway Garage and runs every scenario against it. just bench-compare diffs a fresh run against baseline.json and refuses to compare across labels or corpus versions; each environment keeps its own file. The checked-in result JSONs live in benchmarks/.