Namespace Kuestenlogik.Bowire.Benchmarking

Classes

BowireBenchmarkRequest

What to measure and how hard to push (#360).

BowireBenchmarkRun

One completed benchmark run.

BowireBenchmarkRunner

Drives a protocol plugin's invoke path in a loop and collects latencies (#360). Deliberately thin: it owns concurrency, warm-up and timing, and leaves the transport to IBowireProtocol — the same seam bowire call and bowire test invoke through, so a benchmark measures the request path the rest of the tool actually uses.

BowireBenchmarkSchedule

A benchmark that fires on a cron schedule (#232).

The schedule carries the whole request rather than pointing at a workbench envelope on purpose: envelopes live in the browser's localStorage, and a hosted service running in the server process cannot read those. Persisting what to call — and how hard — next to the cron expression is what lets a schedule survive a restart and run with no operator present, which is the point of the ticket.

BowireBenchmarkScheduleEndpoints

The benchmark-schedule HTTP surface.

BowireBenchmarkScheduleRun

One recorded execution of a scheduled benchmark (#232).

BowireBenchmarkScheduleStore

On-disk store for benchmark schedules and their run history (#232), under .bowire/benchmark-schedules/.

Persistence is the restart-survival requirement: the hosted service holds no schedule state of its own, it re-reads this directory on boot. One JSON file per schedule, plus a sibling <id>.runs.json holding the newest-first history, so a run appended by a firing never rewrites the schedule definition an operator may be editing.

BowireBenchmarkScheduleThreshold

A threshold verdict recorded with a scheduled run.

BowireBenchmarkSchedulingEndpointContribution

Mounts the schedule API for the workbench (#232).

BowireBenchmarkSchedulingHostedService

Fires scheduled benchmarks (#232).

Holds no schedule state of its own: it re-reads the store on every tick, which is what makes a schedule survive a restart (the entry is on disk, not in memory) and also means an operator adding, pausing or deleting a schedule takes effect without a bounce.

A run is due when its next cron occurrence has passed since the last time this service looked. Comparing against the schedule's own last-run timestamp — rather than an in-memory timer — keeps a missed window (host asleep, deploy in progress) from silently swallowing the run, and keeps a restart from re-firing one that already happened.

BowireBenchmarkSchedulingServiceContribution

Registers the scheduling backbone (#232). Discovered by Core's service contribution scan, so referencing the Benchmarking package is all a host has to do to get scheduled runs — and a host that doesn't reference it starts no scheduler at all.

BowireBenchmarkStats

Aggregate latency statistics over one benchmark run (#360).

Percentiles use nearest-rank — ceil(p/100 × n) − 1 into the sorted sample — which is the method the workbench's benchmark rail has always used (_percentileSorted in benchmarks.js). Matching it matters more than picking a "better" interpolation: an operator who sees p95 = 142 ms in the rail and then gates CI on p95 < 150 must not get a different number from the CLI for the same sample.

BowireBenchmarkThreshold

A latency / error / throughput budget a benchmark run must satisfy (#360) — k6's threshold concept, expressed the same way flow expectations are, so an operator learns one grammar.

Written as metric operator budget: p95 < 200, error-rate < 0.01, throughput >= 50. Whitespace is optional and k6's own p(95) spelling parses too, so a budget copied out of a k6 script keeps working.

BowireBenchmarksRailContribution

Benchmarks rail contribution (#306 Phase G).

BowireK6Summary

Renders a run as k6-summary JSON (#234 shape, #360 thresholds).

The metric block mirrors what the workbench rail already exports (http_req_duration / http_reqs / iterations / iteration_duration / http_req_failed / checks), so a dashboard that ingests a run exported from the UI ingests one written by bowire bench run without a second code path.

Thresholds ride along the way k6 itself reports them: keyed by their source text inside the metric they constrain, each with an ok flag. That is what makes "downstream tooling agrees" true rather than aspirational — a CI dashboard reading k6 summaries finds Bowire's budgets exactly where it looks for k6's.

BowireRegistryProtocolResolver

Resolves scheduled runs' protocol plugins through the process-wide protocol registry — the same set the workbench and CLI discover.

BowireScheduleEnabledRequest

Pause / resume body for the schedule endpoint.

BowireThresholdResult

Outcome of checking one threshold against a run.

Interfaces

IBowireBenchmarkProtocolResolver

Resolves a protocol plugin by id for the scheduler. An interface rather than a direct registry call so the hosted service can be driven in a test without a plugin scan, and so a host can narrow which protocols scheduled runs may reach.

Enums

BowireBenchmarkMetric

A metric a threshold can be set on (#360).

BowireThresholdOperator

Comparison a threshold applies between the measured value and the budget.