Expand description
Side-by-side latency for the two repo backends.
The cutover runs one backend at a time behind a flag, so the comparison is
across a flip rather than within a request. That makes the shape of the
measurement the thing to get right: both paths are timed at the same
boundary — the call site in web.rs, which is what a user’s request
actually waits on — by one wrapper rather than two hand-placed timers, so a
difference in the numbers is a difference in the backends.
Failures are timed separately from successes. A backend that is fast because it is erroring out early would otherwise look like a win, and that is precisely the regression a cutover needs to catch.
Structs§
- Repo
Metrics - The process-wide table. Cheap to clone into handlers via
AppState. - Row
- One rendered line: a backend, an operation, and its timings.
- Stats
- Timings for one (backend, operation) pair.
Enums§
- Backend
- Which repo implementation served a call.
Functions§
- flush
- Write the buffered samples and prune each key back to its window.
- persisted_
rows - Read the persisted rows for BOTH backends.
- render
- Render a snapshot as a plain-text table.
- timed
- Time one repo call and record it.