ced4568
51a09241ad
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.
1.2 KiB
1.2 KiB
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_coreswith the peak CPU figure above - Updated
measured_lab_mem_mbwith the peak memory figure above - Re-ran
infra/scripts/capacity-model.jsand recorded the new recommended-concurrent-Labs number