Avatar for the routers-org user
routers-org
routers
BlogDocsChangelog

Performance History

Latest Results

feat: Include licensing section in README Added licensing information for software usage. Signed-off-by: Ben White <37007079+bennjii@users.noreply.github.com>
main
11 hours ago
feat(infra): model shard-to-pod arity, collapsing the low-end pod floor The model could express one direction of the shard-to-pod mapping and not the other. Many pods per shard was covered — a shard's load exceeding one pod, split by the queue group — but many shards per pod was not, so a shard could never share. That put a floor of one pod per shard under every deployment regardless of traffic, and below the knee that floor is the entire bill: 256 pods to carry 1250 evt/s. Both directions are the same statement about throughput, so one expression covers them and the crossover needs no special case. A pod worth 6000 evt/s against a shard carrying 5 should hold more geography; against one carrying 39000 it should be one of seven. At 32 shards and 1k evt/s, arity 6 takes matchers from 32 pods to 6, the matcher pool from 3 nodes to 1, and the bill from $7180 to $4667. It also saturates quickly: past about 6 the matcher pool is already one node and the remaining floors are the other pools', so arity alone stops at 6 nodes. Combined with the shared layout it is 8 pods on one node. Above the knee it disappears on its own. At 800k over 256 shards the arity is 1 and every figure matches what the model produced before this existed, so the high-volume behaviour is untouched by construction. Arity trades pods for per-pod memory, since a pod holds a graph per shard, and it is not yet known whether the fixed 88 MiB term amortises across them — both measurements come from a process holding one network. `shard_memory_fixed_is_per_process` defaults to the conservative answer. Loading two shards into one matcher and reading its RSS would settle it. Deploying this needs a matcher change, not a wire change: `ShardLoader::load` already returns a network per shard from a cache map, and a request subject's last token says which shard it belongs to, so a pod can hold several networks and pick per request. The per-shard solver is unchanged; there are simply several in one process. The orchestrator still addresses `events.match.<shard>` and never learns which pod answers. 27 capacity tests pass, three new: that arity collapses the floor, that it self-disables above the knee with figures identical to before, and that fleet-wide graph memory still falls.
feat-terraform-realtime-migration
3 days ago

Latest Branches

CodSpeed Performance Gauge
0%
feat: Reuse Dijkstra Working Buffers#228
14 hours ago
d02d04e
fix-dijkstra-buffer-reuse
CodSpeed Performance Gauge
-1%
16 hours ago
96742be
fix-cache-correctness
CodSpeed Performance Gauge
0%
feat: Infrastructure Tools in Flake#226
3 days ago
b6e247b
feat/nix-terraform-support
© 2026 CodSpeed Technology
Home Terms Privacy Docs