Files
ITWorx-Pulse-Public/docs/engineering/PERFORMANCE_BUDGETS.md
T
ITWorx Pulse release export bd774932d5
Public source validation / validate (push) Failing after 3m8s
Publish ITWorx Pulse source
2026-09-03 02:09:19 +02:00

74 lines
2.4 KiB
Markdown

# Performance budgets
Budgets are acceptance targets measured in the documented test environment.
## Target scale
- 1 Unraid host;
- 150 containers;
- 40 disks;
- 300 service probes;
- 2,500 active series across an intensive dashboard set;
- 10 concurrent authenticated users;
- 1 wallboard open for at least 24 hours.
Container ingestion retains bounded headroom up to 250 records so a host that
briefly grows beyond the 150-container performance target remains observable.
The 150-container fixture remains the required latency and UI acceptance scale;
the additional headroom is a safety boundary, not a higher performance claim.
## Browser
| Metric | Target |
|---|---:|
| First meaningful overview on LAN, warm service | < 2.0 s |
| Main route interaction ready | < 3.0 s |
| Live sample visual delay | < 2.5 s at 2 s interval |
| Drag/resize frame behavior | no sustained visible jank |
| 24 h wallboard heap | bounded; no monotonic leak |
| Active subscriptions after navigation | returns to expected baseline |
| Large table scroll | responsive with virtualization |
Record browser, hardware and network.
## API
| Metric | Target |
|---|---:|
| P95 cached/config API | < 250 ms |
| P95 24 h bounded range query | < 750 ms excluding unavailable upstream |
| P95 inventory list | < 500 ms at target scale |
| WebSocket reconnect | automatic within 10 s under normal recovery |
| Error response | bounded and correlated |
## Resource envelope
Initial production goals, to validate:
- API/worker/agent combined idle memory should remain reasonable for Unraid;
- CPU near idle outside query/evaluation bursts;
- database growth predictable under retention;
- no unbounded goroutines, queues, caches or event payloads.
Do not invent a pass. Record actual values and refine budgets through an ADR if hardware/source constraints provide evidence.
## Query limits
- max series and points per request;
- max concurrent upstream requests;
- step adjusted to viewport/time range;
- heavy query rejection with guidance;
- metadata/label enumeration bounded.
## Tests
- frontend bundle analysis;
- Lighthouse or equivalent where meaningful;
- scripted dashboard load;
- WebSocket fan-out/load;
- Prometheus slow/error injection;
- real wallboard soak of at least 17 hours under the explicit M10-14
product-owner duration decision;
- worker/probe concurrency;
- database query plans for large lists;
- restart/recovery under load.