Every official Capsid release, re-measured end to end on one
dedicated machine under a frozen protocol — throughput, cold
start, and process-level memory, against the runtimes you
actually deploy.
01 — Serving
Throughput
Closed-loop load generation with the repository's frozen
client: 64 keep-alive connections, 64 in-flight, 5 s warm-up plus
five 15 s measured rounds. Every round verifies the exact
response body; medians are reported.
Requests per second
median of rounds — higher is better
Median throughput (req/s) — Capsid’s row highlighted
Per-request latency (ms) in the last measured round — lower is better
02 — Density
Serving memory
Proportional set size from
smaps_rollup, decomposed into each stack's
real processes. Two windows: an equal-load trickle (10 req/s on
a fresh process — same request volume everywhere) and after the
last measured round of the 64-connection load. The trickle read is
the fair at-rest comparison; the loaded read shows how each runtime
behaves under real pressure.
At a trickle — 10 req/s
process-tree PSS after 15 s of gentle traffic on a fresh
process, before any load — the at-rest footprint, MB
Under load — 64 connections
process-tree PSS stacked by component, MB — lower is better
Marginal cost per serving worker
the worker process alone — amortized infrastructure
(capsid host, nginx, masters) excluded. workerd runs worker and
server inside one process, so its bar is that whole process — an
upper bound on its per-worker cost. MB — lower is better
Measured density — fill a pool until it hits 2 GB
Real runs: grow capsid's static pool (or workerd's cell
count in one process) until the process tree's PSS reaches the 2048 MB
budget, binary-searching the boundary. Cold rows initialize
every worker/cell with one real request; warmed rows drive 100
requests through each first. The gap between the two is the runtime's
memory behaviour under traffic — capsid barely moves (no JIT, heap
flat), while workerd's V8 compiles and grows under load and never
returns the memory. Final pool PSS in parentheses.
03 — Instantiation
Cold start & footprint
Process start → ready → first response. One warm-up run
is discarded and the median of five rounds is reported. All runtimes
load the same fixture source, byte-aligned, differing only in the
entry point.