measures the round-trip through this dashboard proxy (browser → Python → gateway) — a demo path, not the exchange’s internal µs round-trip.

next → Orders

End-to-end (GW → ME → GW, real)

End-to-end probe: WS → Gateway → Risk → ME → Risk → Gateway → WS, measured by submitting a marketable order and waiting for the F (fill) frame on the same WebSocket. Requires the maker to be running so there is liquidity to cross.

loading...

Gateway round-trip (live, playground ↔ gateway)

Live measurements from the running system. /api/latency tracks the gateway round-trip on every order submission (playground → gateway → playground). See Docsspecs/2/22-perf-verification.md for what these numbers do and don't cover.

loading...

Component microbenches (Criterion, single thread)

match single fill
54 ns
rsx-book bench
WAL append (in-mem)
31 ns
rsx-cast bench
cast encode
43 ns
rsx-gateway bench
cast decode
9 ns
rsx-gateway bench
SPSC ring hop
50–170 ns
rtrb bench
WAL flush + fsync 64 KB
~24 µs
rsx-cast bench

Run locally with make perf or make bench-gate (10% regression check vs saved baseline).

Design budgets (not measured E2E yet)

The headline targets — documented but not yet asserted by an automated end-to-end harness. Use the live probe above to measure the round-trip on this box.

Path Target State
ME match (single fill) < 500 ns measured 54 ns
Risk pre-trade < 5 µs budget, no harness
GW → ME → GW round-trip < 50 µs budget, no harness
Gateway WS frame < 50 µs budget, no harness

The gateway round-trip card above measures the playground ↔ gateway path (Python → aiohttp → gateway WS → JSON → JWT → cast → reverse). It overstates the matching latency — it's useful as a liveness signal, not as the <50 µs claim.

Regression vs published baseline

loading...