Adaptive engine — dual-engine controller

[FumingPower3925]

Summary

Meta-engine that runs two engines concurrently (active/standby) and switches between them based on runtime telemetry. Implements the Engine interface.

Dual-Engine Architecture

• Active engine handles all new connections
• Standby engine is warm (initialized, no traffic)
• Switch = redirect new connections to standby, drain active

Telemetry Signals

Signal	Source	Weight
p99 latency	Engine metrics	0.25
Throughput (req/s)	Engine metrics	0.20
SQ utilization	io_uring ring stats	0.15
Event loop busy%	epoll loop timing	0.15
Syscall rate	/proc/self/status	0.10
Connection count	Engine metrics	0.05
Error rate	Engine metrics	0.05
CPU utilization	/proc/stat	0.05

Switching Logic

• Evaluation window: 5 seconds
• Weighted scoring: each signal normalized 0-1, weighted sum
• Switch threshold: 15% score improvement predicted
• Hysteresis:
  • 30s cooldown after any switch
  • 10s minimum observation window
  • Oscillation lock: 3 switches in 5 minutes → lock for 5 minutes

Initial Engine Bias

Protocol	Initial Engine
HTTP/1.1	io_uring
H2C	epoll
Auto	io_uring

Connection Draining

• No FD migration between engines
• New connections go to new active engine
• Old connections drain naturally (5 minute timeout)
• Combined memory cap enforced during dual-engine operation

Tests (SDD 14.3)

• Initial bias: H1 → io_uring, H2C → epoll, Auto → io_uring
• Switch trigger: inject telemetry showing 20% improvement → switch occurs
• Hysteresis: switch → attempt immediate re-switch → blocked by cooldown
• Connection draining: old connections complete, new go to new engine
• Oscillation lock: trigger 3 switches in 5 min → locked
• Overload freeze: Adaptive frozen when Overload stage ≥ 3
• Synthetic telemetry injection for deterministic testing

SDD Reference

Section 7 (full), 14.3

Dependencies

Depends on #7, #9