barrage v0.7.0Go

Is it your app, or the database underneath it?

HTTP, database, and Redis driven on one shared clock, bucketed onto one timeline. Every latency spike gets blamed on the layer that actually caused it.

install latest release

$ curl -fsSL https://raw.githubusercontent.com/codetesla51/barrage/main/install.sh | bash

github.com/codetesla51/barrage ★ 96

$ barrage run -c config.yaml 15s · bucket 1s · c10

RUNNER  REQUESTS  SUCCESS  MEAN    P95     P99
http    135       100.0%   927µs   2.5ms   4.4ms
db      67        100.0%   12.9ms  69.0ms  136.2ms
redis   269       100.0%   797µs   2.3ms   3.5ms

correlated spikes
TIME      RUNNER  HTTP_P99  STORAGE_P99  NOTE
20:52:22  db      <100ms    136.2ms      db-only

p99 latency by bucket

http db redis threshold 100ms

31×db p99 over http136.2ms ÷ 4.4ms

Postgres spiked to 136ms while the API never left 4ms. One latency curve would have shown a perfectly healthy service. The bottleneck is already there, it just hasn't backed up yet.

some features

auto-ramp: Doubles concurrency until a layer breaks, then fine-fills to pin the exact level, and names which runner caused the break.
capacity finder: Maps buckets to active users and reports where it starts straining, instead of handing you a number to interpret.
compare & CI gate: Diff two JSON runs, exit non-zero when a P99 crosses budget. A regression fails the pipeline before it ships.
scenario mode: Weighted user journeys with per-virtual-user token extraction and {{var}} interpolation across steps.
masked spikes: Storage spiked but HTTP held? Still flagged. That's the bottleneck you find before your users do.
chaos mode: Break dependencies on a schedule while the load runs — take the db proxy down, inject 500ms, reset peers — and see which layer actually degrades.