boot-labs.js drives the real admin Prepare-Labs endpoint (reusing the existing session-helper.js from Phase 3A) and records boot time/failure rate; sample-resources.sh samples real docker stats for running Labs. capacity-model.js turns measured per-Lab CPU/memory into a recommended/ warning/hard-admission-control concurrency threshold - no concurrency number is hardcoded as a marketing figure, every input is explicitly placeholder data until measured against the real host. Plus deploy/rollback/smoke-test scripts used by the CI/CD and deployment runbooks. All syntax-checked; validate-compose.sh and capacity-model.js actually run against real inputs.
37 lines
1.2 KiB
Markdown
37 lines
1.2 KiB
Markdown
# RootNode Load Test Report
|
|
|
|
**Date:** _______
|
|
**Ran against:** [ ] dev laptop [ ] staging [ ] production rn-lab-host-01 (real hardware)
|
|
**Host spec (fill in real numbers, do not guess):** ___ cores / ___ threads / ___ GB RAM / ___ storage
|
|
|
|
> A run against anything other than the real target-class hardware only tells you the code
|
|
> path works, not what production can actually sustain. Say clearly which this is.
|
|
|
|
## Boot test (`boot-labs.js`)
|
|
|
|
| Metric | Value |
|
|
|---|---|
|
|
| Requested Lab count | |
|
|
| Successfully running | |
|
|
| Failed | |
|
|
| Failure rate | |
|
|
| Total wall-clock time (concurrent boot) | |
|
|
|
|
## Resource usage (`sample-resources.sh`)
|
|
|
|
| Metric | Value |
|
|
|---|---|
|
|
| Peak CPU per Lab (observed) | |
|
|
| Peak memory per Lab (observed) | |
|
|
| Peak disk I/O per Lab (observed) | |
|
|
| Host CPU headroom remaining at peak | |
|
|
| Host memory headroom remaining at peak | |
|
|
|
|
## Feed into docs/CAPACITY_PLANNING.md
|
|
|
|
- [ ] Updated `measured_lab_cpu_cores` with the peak CPU figure above
|
|
- [ ] Updated `measured_lab_mem_mb` with the peak memory figure above
|
|
- [ ] Re-ran `infra/scripts/capacity-model.js` and recorded the new recommended-concurrent-Labs number
|
|
|
|
## Notes / anomalies observed
|