Improve KVM connection performance in Console

[graikhel-intel]

Description

We’ve noticed that KVM connections in Console can feel slower than expected, and there may be opportunities to improve the startup time.

One area worth looking at is how often we call device-related APIs. When a device is first opened in Console, we already fetch information such as user consent, general settings, and activation status. When switching to the KVM tab, some of these same calls are made again, which could be contributing to the delay.

This story is to explore what we can do to make KVM connections faster, such as reusing or caching existing data, and to evaluate any other ideas that could help improve the overall experience.

Most of the feedback so far is from the Console enterprise deployment, but it would be good to see if the same improvements can also apply to the Cloud deployment.

Acceptance Criteria

• Potential optimizations to improve KVM startup time are identified and evaluated.
• Implemented changes result in faster KVM connection setup.
• No negative impact to existing KVM behavior or user experience.

[nmgaston]

Story 1: Add Performance Timing Instrumentation

Story created -> #756

NOTES: Create this story. Looks at creating telemetry data using permetheus to permanently capture time to connect. Other metrics such as 2nd, 3rd loading would be temporary metrics to measure improvements.**

Applies To: Enterprise (console backend)

Description: Add detailed timing logs at key stages of KVM connection flow to identify bottlenecks.

Proposed Changes:

• Add KVM_TIMING logs in internal/usecase/devices/interceptor.go
• Add KVM_TIMING logs in internal/controller/ws/v1/redirect.go
• Track: device lookup, connection setup, RedirectConnect, WebSocket upgrade, total time

Expected Benefit:

• Enable data-driven optimization decisions
• Identify bottlenecks (consent codes, API latency, connection setup)
• Baseline for measuring future improvements

Effort: Low (2-4 hours)
Risk: Very Low (logging only, no functional changes)

---

Story 2: Cache Consent Codes in Backend

NOTE: There should be a 3 minute timer already before asking for the AMT user consent code. Double check this, but this story shouldn't be necessary.

Applies To: Enterprise (console backend)

Description: Cache AMT user consent codes in memory with 2-minute TTL to avoid redundant requests to AMT firmware.

Expected Benefit:

• ~100% cache hit rate after first request within 2-minute window
• Saves 120-150ms per cached consent code request
• Reduces load on AMT firmware
• Typical scenario: 3 consent code calls → 1 call (first load only)

Effort: Low (4-6 hours)

• Implement cache structure and logic
• Add cache invalidation on SendConsentCode/CancelUserConsent
• Testing with concurrent requests

Risk: Low

• Must synchronize with mutex (straightforward)
• TTL must match AMT timeout (~2 minutes)
• Cache invalidation on user actions

---

Story 3: Cache Frontend API Responses

Story Created -> #756

NOTE: Create this story. AMT Calls and KVM Display call reduction should give improved performance. We need to be careful with the Power State call reduction because this could not have the correct state due to it changing.

Applies To: Enterprise AND Cloud (sample-web-ui frontend)

Description: Implement 60-second TTL cache in Angular service to avoid redundant API calls when users switch between device tabs.

Expected Benefit:

• Estimated 60-70% reduction in API calls when users revisit KVM tab
• 70-80% cache hit rate for features/power/displays endpoints
• Per-session API calls reduced from ~15-20 to ~5-8
• Estimated ~80-90% faster subsequent KVM session loads

Projected API Call Reduction:

• AMT Features: ~70% fewer calls (e.g., 20 → 6)
• Power State: ~70% fewer calls (e.g., 21 → 6)
• KVM Displays: ~40% fewer calls (e.g., 5 → 3)
• Combined with Story 2: Consent codes from multiple calls → 0-1 per 2 minutes

Effort: Low (4-6 hours)

• Implement cache maps with TTL
• Update service methods with cache-check logic
• Add cache invalidation (e.g., on setDisplaySelection)
• Testing with different navigation patterns

Risk: Low

• Client-side only (no backend dependency)
• Conservative 60s TTL prevents stale data issues
• Graceful degradation on cache miss

Cloud Impact: Cloud deployments benefit equally from reduced load on MPS/RPS APIs

---

Story 4: Parallelize API Calls on KVM Tab Open

NOTE: Low priority. Could try in a POC. This may not be doable

Applies To: Enterprise AND Cloud (sample-web-ui frontend)

Description: Use RxJS forkJoin to make consent code, display settings, and power state calls in parallel instead of sequential.

Current Sequential Flow:

Consent (120ms) → Displays (400ms) → Power (700ms) = 1220ms total

Optimized Parallel Flow:

Consent (120ms) ┐
Displays (400ms) ├─ forkJoin → 700ms total (longest call)
Power (700ms)    ┘

Expected Benefit:

• 42% faster KVM tab load (1220ms → 700ms)
• Combined with Story 4 pre-fetch: ~0ms perceived time
• Combined with Story 3 caching: Most calls served from cache (~10ms)

Effort: Low (3-4 hours)

• Refactor KVM component to use forkJoin
• Update error handling for parallel requests

Risk: Low

• Well-established Angular pattern
• Need proper error handling (partial failures)
• Test with network delays

Cloud Impact: Same improvement for cloud API calls

---

Story 5: WSMAN Connection Pooling

NOTE: This has been tried in the past. Could try again, but it may have a broader impact than just KVM.

Applies To: Enterprise (console backend), Cloud (MPS backend - separate effort)

Description: Maintain pool of authenticated WSMAN client connections per device. Reuse connections instead of creating new ones for each request.

Expected Benefit:

• ~35ms saved per WSMAN request (connection setup + auth)
• Helps consent code, display settings, and power state calls
• Cumulative benefit: ~100-140ms per KVM session

Effort: Medium-High (16-24 hours)

• Implement connection pool with TTL
• Add connection health checks
• Handle connection cleanup on device disconnect
• Thread-safe operations with proper locking
• Extensive testing required

Risk: Medium

• Connection state management complexity
• Potential memory leaks if not cleaned up
• AMT firmware connection limits (need testing)
• Stale connection handling
• Concurrent access race conditions

Cloud Impact: Would require separate implementation in MPS backend (different codebase)