Chapter 13: Feature Goals — What We're Optimizing and Why
The Business Problem
Customers buy hardware to support N subscribers. If our software uses more CPU per session, customers need more hardware = more cost. The feature must NOT increase CPU usage — ideally it DECREASES it.
Success Criteria (from architect sync)
- DP control+spare CPU: no more than 10% increase (ideally decrease)
- Throughput: no degradation at same CPU level
- Latency: no more than 20ms p99 for 5GC MBB workload
- PEP/KVDB CPU: less concern (easier to scale out)
What's Being Optimized
| Change | Expected Benefit | Risk |
|---|---|---|
| DP: db-proxy → db-mux | 2.5× less CPU for DB operations | Higher per-command latency |
| DP: individual SETs → MSET | Less Redis parsing, fewer callbacks | Hash slot constraints in cluster |
| PEP: db-proxy → db-mux | CPU savings | Possible throughput regression |
| Signaling: TCP/TLS cork | Fewer TCP segments on HTTP/2 path | Complexity, marginal gain |
What's NOT Being Done
- Futex wakeup in PEP (rejected — no benefit)
- Rest hubber in PEP (on hold — too complex for uncertain gain)
- Time-based batching in db-proxy (db-proxy being replaced entirely)
- PEP DB batching across sessions (not possible — different hash slots)