# Load test tooling

Two scripts, run together against whatever stack you point them at:

- `boot-labs.js` — provisions N Labs concurrently via the real admin Prepare Labs endpoint,
  measures boot success rate and wall-clock timing. `GATEWAY_URL=... OWNER_EMAIL=...
  OWNER_PASSWORD=... node boot-labs.js --count=10`
- `sample-resources.sh` — run on the Lab Host **while** `boot-labs.js` runs, samples real
  `docker stats` for every `rootnode-lab-*` container every 5s, writes CSV.

```bash
# terminal 1, on the Lab Host:
./infra/scripts/loadtest/sample-resources.sh 180 ./results/run1.csv

# terminal 2, wherever the Gateway is reachable from:
GATEWAY_URL=https://academy.example.com OWNER_EMAIL=... OWNER_PASSWORD=... \
  node infra/scripts/loadtest/boot-labs.js --count=10
```

`report-template.md` is a filled-in-by-hand summary format — copy it, paste the two scripts'
output in, note the host class it ran against. **A run against a dev laptop is not evidence
about the real Hetzner host** — every report must say what it ran on.

Feeds `docs/CAPACITY_PLANNING.md`'s worksheet directly: `sample-resources.sh`'s peak
`mem_usage`/`cpu_pct` per Lab are exactly the "measured Lab CPU"/"measured Lab RAM" inputs that
worksheet asks for.

Test dimensions this DOESN'T cover yet (documented gaps, not silently skipped): terminal
WebSocket throughput under concurrent load, Gateway HTTP throughput independent of Lab boot,
and steady-state (long-running, not just boot-burst) resource drift. Extend `boot-labs.js`'s
pattern (it already reuses `platform/test/session-helper.js`) rather than building a separate
tool if/when those are needed.