What a 100-machine burst measures
Mainbrella’s historical burst result reports 100 successful concurrent starts with a P95 of 680 ms. A separate creation test reports 30 successes, a P50 of 381 ms, and a P95 of 528 ms. Those are prototype observations. The original raw samples, harness, test date, region, image, and timing boundaries are missing from this repository.
That missing context prevents a comparison with another platform’s startup number. It also prevents treating the result as a cold-start measurement or an estimate of today’s API latency. The benchmark record keeps both the observations and those gaps visible.
Measure the work the client needs
The current HTTP benchmark uses the same verification workflow as agent onboarding. Each sample creates its own container with an idempotency key, waits for a matched running generation, executes a hello command, checks its exit code and output, writes and reads a six-byte binary probe, and attempts cleanup.
It records creation time from the first launch request through the returned running state, including creation retries. It separately records time through the first command response. File verification and cleanup determine whether the sample passes, but are outside those two timing intervals.
A reported running machine and a validated command are different milestones. Recording both makes the gap visible. The runner records the number of creation requests, sample outcomes, selected catalog ID, account limits, and client metadata alongside the timings.
Keep the failures
The runner launches work in batches up to the requested concurrency and waits for each batch’s cleanup. If a sample fails, it halts after that batch. It does not launch replacement reservations to fill out a successful-looking sample count. Its nearest-rank P50 and P95 summaries use successful samples; attempted and successful counts and individual failures remain in the JSON.
The report labels image cache state as uncontrolled and compute region as unreported. A new creation identity alone cannot prove that a host or image cache was cold. Keep the runner version with the raw report so a future reader can inspect the timing boundaries and percentile calculation.
Run within an allowance
Read-only preflight checks must establish available starts, slots, and the selected runtime image before launch. Each sample consumes a start, so the sample count needs explicit authorization. A 100-machine test requires enough account concurrency and allowance; it is not a Builder-plan quickstart.
The reproducible HTTP benchmark runner and verification source are public. This article reports no new benchmark run. Follow the run instructions when collecting a new record.