100k Burst Concurrency Benchmark

Benchmark phases

Allocate

— time from sandbox.create() until the API confirms the sandbox exists.

Readiness

— time from sandbox creation until node -v executes and returns successfully inside it.

Alive

— in concurrency charts, the window a sandbox is held open after its initial readiness probe until teardown. The second liveness check runs during this window — a sandbox that fails it appears alive in the chart but is counted as partial.

Worker point

— in the latency scatter chart, each point represents the median latency of a group of sandboxes from one worker, ordered by submission index. The group size scales so roughly 1,000 points appear regardless of run size.

VM metrics

Each VM managed up to 140 sandboxes. One thousand ran in parallel to produce the full 100,000+ sandbox burst. System metrics shown here reflect a single coordinator VM's resource usage — all 1,000 coordinators ran on identical hardware.

RSS

— resident set size: total physical RAM the process occupied, including code, stack, and all heap pages loaded into memory.

Heap used / Heap total

— V8-managed memory for JavaScript objects. Used is live data; total includes GC headroom reserved but not yet filled.

Event loop lag

— delay between when a callback was scheduled and when it actually ran. High p99 lag means the coordinator was CPU-saturated and some requests stalled in the queue.

Open FDs

— open file descriptors: each outbound HTTP connection to the provider API consumes one. Peak FDs reflect peak request concurrency from the coordinator's perspective.

TCP inuse

— TCP connections in an active state (ESTABLISHED, SYN_SENT, etc.) at any moment, read from .