Chapter 18: Performance Metrics — CPU%, Rate@80%, Latency p99
Key Metrics Explained
| Metric | What It Means | Why It Matters |
|---|---|---|
| avg CPU DP control | CPU usage of DP control thread (%) | Main logic thread — if saturated, can't handle more sessions |
| avg CPU DP spare | CPU usage of DP spare thread (%) | DB I/O thread — becoming the bottleneck |
| avg CPU DP ctrl+spare | Combined average | Overall DP CPU health |
| avg CPU KVDB | Valkey server CPU (%) | If high, Redis is the bottleneck |
| Rate @80% vCPU | Sessions/sec achievable at 80% CPU (normalized to 1 pod) | Capacity metric — higher = more efficient |
| Create/Modify/Delete rate | Actual rate sent to SUT | The load being applied |
Understanding "Rate @80% vCPU"
// Example from test results:
// Create rate: 7200 (actual rate sent, 2 pods)
// Create avg DP CPU: 68% (measured across 2 pods)
// Create rate @80% vCPU: 4207 (calculated for 1 pod at 80%)
// Calculation (assuming linear scaling):
// 7200 rate / 2 pods = 3600 per pod
// 3600 rate at 68% CPU → at 80% CPU: 3600 × (80/68) = 4235 ≈ 4207
// This normalizes results so you can compare across different test runs
// Higher rate@80% = more efficient (can do more work per CPU%)What "Good" Looks Like
- Rate@80% increases → feature made us more efficient (good!)
- Rate@80% decreases → feature made us less efficient (bad! regression!)
- CPU% decreases at same rate → feature uses less CPU (good!)
- CPU% increases at same rate → feature uses more CPU (bad!)
Target from Architect
Klas (system architect) said: "roughly 20ms and not more than 10% higher load on 5GC MBB could be an internal target." This means:
- Latency: stay under 20ms p99
- CPU: no more than 10% increase vs baseline