Runtime SLO dashboard: handler p50/p95/p99 latency, GC pause cost, allocation pressure, client update throughput, and queue backpressure — updated every second
- p50 (median): Typical handler processing time after an event is dequeued.
- p95: The "busy period" handler latency — what happens during market opens.
- p99: Handler tail-latency SLO target: <20ms. Queue wait is tracked separately.
- Peak: Maximum observed handler outlier. If it dwarfs p99, check GC activity and queue buildup.
- GC pause %: Normalizes cumulative GC pause time against process uptime.
- Queue depth: Event-driven latency usually starts as backpressure before it appears in p99.
Handler Latency Percentiles (Live) Handler target: <20ms Peak context: —
Production Signals (Last 60s)
HANDLER P99 LATENCY TREND
—
0ms20ms SLO
QUEUE DEPTH TREND
—
0max —
Throughput
CLIENT UPDATES/SEC
0
SignalR/UI update rate, not raw market-data generation rate.
UI SNAPSHOTS SENT
0
TOTAL BYTES
0
processed
UPTIME
0s
Queue Backpressure
QUEUE DEPTH
0
Pending events in the bounded 100,000-capacity OMS channel.
QUEUE OCCUPANCY
0.0%
0 / 100,000 capacity
UI SNAPSHOTS COALESCED
0
Client/UI snapshots intentionally coalesced during bursts; market-data journal stays lossless.
LOSSLESS STORE QUEUE
0
Journal/replay path is separated from UI coalescing.
QUEUE CAPACITY: 100,000
0.0% occupied / max 0.0%
Garbage Collection
Gen0 collections are cheap but frequent. Gen2 collections cause full STW (stop-the-world) pauses. This system uses ArrayPool<T> for percentile buffers and pre-allocated batch lists to minimize Gen0 pressure.
GEN 0
0
+0 since last
GEN 1
0
+0 since last
GEN 2
0
+0 since last
HEAP SIZE
0
MB
GC PAUSE %
0
0 ms total
LATENCY MODE
—
Demo workload mode reported by .NET GC.
SERVER GC
—
Allocation Rate
Bytes allocated since last snapshot. Lower is better — high allocation pressure triggers more frequent GC collections.
0
0 KB/sec
10 MB/sec