Sizing & Capacity Planning¶
Read in your language: English · Português · Español
audit-v6 DOCS-OPS: enterprise procurement sizing beyond the "up to ~50 agents" heuristic in the quickstarts. Numbers are grounded in the shipped HPA ceilings and the ResourceQuota; treat them as planning defaults and validate against a pilot run using the invalidation criteria in
MONITORING_TEST_VALIDITY.md.
1. Fleet ceilings (as shipped)¶
| Component | min | max (HPA) | Reconciled to |
|---|---|---|---|
| Playwright agents | 1 | 80 | 320-pod ResourceQuota (k8s/05-resource-quota.yaml) |
| k6 agents | 1 | 200 | same quota (blast-radius cap) |
| Personas | fixed | 100 | 20 countries × 5 |
Raising an HPA ceiling without raising the quota is a no-op (pods stay Pending). The quota is the deliberate blast-radius cap — change both together.
2. Per-pod resource footprint (requests)¶
| Workload | CPU req | Mem req | Notes |
|---|---|---|---|
| Playwright agent | ~0.5–1 vCPU | ~512 Mi–1 Gi | Chromium is heavy; cgroup-aware auto-throttle |
| k6 agent | ~0.25–0.5 vCPU | ~256–512 Mi | Volume generator, lighter |
| Persona (Caddy + backend) | ~0.3–2 vCPU | ~512 Mi–2 Gi | real-app (Saleor/Ghost/Gitea) at the high end |
| Dashboard / Postgres / PgBouncer | ~1–2 vCPU each | ~512 Mi–2 Gi | control plane |
3. Node sizing by deployment mode¶
| Mode | UCS nodes | Per-node (min) | Fits |
|---|---|---|---|
| Single-node (lab/eval) | 1 | 16 vCPU / 64 GB / NVMe | ~50 agents + reduced persona set |
| Dual-node | 2 | 32 vCPU / 128 GB | agents on UCS-1, personas+services on UCS-2 |
| Tri-node | 3 | 32 vCPU / 128 GB | Playwright / k6 / personas+services split |
| Multi-node (max) | 4 | 48+ vCPU / 192+ GB | full 80+200 agent fleet + 100 personas |
Host kernel tuning (DaemonSet 85-node-tuning) is mandatory for QUIC at load:
UDP rmem_max/wmem_max = 64 MB, BBR + fq qdisc, CPU governor performance.
4. Throughput classes (what a run can drive)¶
Actual CPS/throughput depends on the DUT and the node fleet. Class the target before sizing:
| Class | Intent | Fleet guidance |
|---|---|---|
| Functional | decrypt-on/off correctness, small mixes | single/dual-node, ≤50 agents |
| Capacity | sustained CPS + throughput to a mid-range NGFW | tri/multi-node, k6 fleet 100–200 |
| HTTP/3 pressure | QUIC handshake-rate (cps mode) | h3loadgen replicas sized to the H3-ONLY test plans; set a FIXED replica count matched to target CPS — never an HPA (a load generator must not autoscale mid-run; see pkg/h3loadgen/README.md) |
5. Storage & growth¶
| Data | Location | Growth driver |
|---|---|---|
| Postgres (control) | StatefulSet PVC | audit log (WORM, append-only), token ledger, tickets |
| Cloned-persona content | NFS (dut-system) |
operator clone actions (bounded by slot count) |
| Prometheus | TSDB PVC | scrape cardinality × retention |
Budget the WORM audit log for steady append growth; it is never truncated in place (retention is a separate archival step).
6. Method¶
- Pick a throughput class (§4).
- Size nodes (§3) for the agent fleet that class needs.
- Run a pilot; if any invalidation signal fires
(
HostUDPBufferOverflow, conntrack > 80%, CPU > 85% + p99, HPA pinned), the test bed — not the DUT — is the bottleneck; scale up and re-run.