Chaos Frontend

Les 4 anomalies frontend s'exécutent dans le navigateur de l'apprenant, pas dans le container Nginx. Nginx sert uniquement les fichiers statiques.

Où s'exécute le chaos ?

Le chaos frontend tourne dans le moteur JavaScript du navigateur (V8 sur Chrome). Le container perfshop-frontend restera toujours à ~0% CPU — c'est normal. Les métriques à observer sont dans la section Navigateur client du dashboard.

Architecture

chaos-agent.js est chargé par le frontend React. Il poll GET /api/chaos/frontend/state toutes les 5 secondes et applique les anomalies actives. Il remonte les métriques vers le monitoring via POST /api/chaos/client-metrics toutes les 2 secondes.

applyState() ne redémarre une anomalie que si sa valeur a changé — pas de reset inutile si l'état est identique. Les clés inconnues reçues de l'API sont ignorées (whitelist KNOWN_KEYS).

---

1. CPU Burn 🔥

Deux niveaux simultanés :

Web Worker (thread OS réel)

// fixedRate = 100ms — même pattern que CpuChaosScheduler.java
// iterations = intensity × 3200
timer = setInterval(runBurn, 100);

Le Worker est créé via une Blob URL révoquée immédiatement après instanciation — évite l'accumulation d'URLs en mémoire si le slider est bougé souvent.

Visible dans le gestionnaire de tâches du navigateur (onglet Performance de Chrome DevTools).

Thread principal (Long Tasks + FPS)

// 150ms de blocage toutes les 100ms à 100%
const blockMs  = Math.floor(pct * 150);
const repeatMs = 100;

Génère des Long Tasks (>50ms) détectées par PerformanceObserver.

Métriques impactées :

Métrique	Nominal	À 50%	À 100%
FPS	~144	~40	~10
Long Tasks/s	0	~7	~15
CPU Worker	OFF	ON	ON

---

2. Memory Leak 💾

Accumulation d'objets JavaScript en mémoire avec deux mécanismes :

• Objets simples : tableaux, closures — plafond 1.2 Go (MAX_BYTES = 1.2 × 1024³)
• Event listeners orphelins : éléments DOM détachés avec closures volumineuses, jamais collectés par le GC — plafond 50 000 listeners (MAX_LISTENERS = 50_000)

Les deux plafonds sont séparés et indépendants — évite un crash de l'onglet Chrome (limite Chrome ~1.5–4 Go selon l'OS).

Vitesse de montée à 100% : ~60 Mo/s → plafond 1.2 Go atteint en ~20 secondes.

Métriques impactées : - perfshop_client_heap_used_mb → montée rapide et visible (~60 Mo/s à 100%)

---

3. DOM Flood 🌊

Création et destruction rapides de 2 000 nœuds DOM avec reflows agressifs — l'opération la plus coûteuse pour le moteur de rendu du navigateur.

Mécanisme de layout thrashing : - Lecture/écriture alternées sur tous les enfants (plus 1 sur 3) - 4 propriétés forcent un reflow par nœud : offsetHeight, marginLeft, offsetWidth, paddingTop - Total : 2 000 × 4 = 8 000 reflows toutes les 100ms → Chrome ne peut pas batcher

for (let i = 0; i < children.length; i++) {
    void children[i].offsetHeight;                        // reflow lecture
    children[i].style.marginLeft = Math.random() + 'px'; // invalide layout
    void children[i].offsetWidth;                         // reflow lecture
    children[i].style.paddingTop = Math.random()*2 + 'px'; // invalide layout
}

Métriques impactées : - perfshop_client_dom_node_count → oscillations rapides (+2000 nœuds) - perfshop_client_long_tasks_per_sec → monte (reflows = Long Tasks) - FPS → chute visible même sur PC moderne

---

4. Fetch Flood 📡

Lance jusqu'à 200 requêtes GET par seconde vers l'API backend sur 12 endpoints variés :

const FLOOD_ENDPOINTS = [
  `/api/products?size=20`,
  `/api/products?page=1&size=20`,
  `/api/products?page=2&size=20`,
  `/api/products?page=3&size=20`,
  `/api/products?category=AVION&size=10`,
  `/api/products?category=VOITURE&size=10`,
  `/api/products?category=BATEAU&size=10`,
  `/api/products/1`,  // ...jusqu'à /5
];

Les 12 endpoints variés (pagination + catégorie + détail par ID) évitent tout cache HTTP et forcent Spring à exécuter de vraies requêtes SQL à chaque fois.

Comportement côté client : Chrome limite à 6 connexions simultanées par domaine — les requêtes excédentaires se mettent en file d'attente (barres grises "Queueing" dans DevTools Network). Les vraies requêtes de navigation passent devant car Chrome les priorise.

Métriques impactées :

Métrique	À 50%	À 100%
perfshop_client_fetch_req_per_sec	~100	~200
http_server_requests_seconds_count{uri="/api/products"}	monte	monte fortement
Grafana débit HTTP	pic visible	pic fort

---

Vérification en console navigateur

// État en temps réel (toutes les 2s)
setInterval(() => console.table(window.__chaosMetrics), 2000)

Affiche : fps, heapUsedMB, longTasksPerSec, domNodeCount, pendingFetches, cpuWorkerActive.

// Test de connectivité monitoring
fetch('https://perfshop-monitoring.perfshop.io/api/chaos/client-metrics')
  .then(r => r.json())
  .then(d => console.log('stale:', d.stale, 'fps:', d.fps))

---

Validation par anomalie

Anomalie	Où observer	Ce qu'on voit
🔥 CPU Burn	DevTools → Performance → FPS meter	FPS chute, Long Tasks dans la timeline
💾 Memory Leak	DevTools → Memory	Heap monte ~60 Mo/s, plafonne à 1.2 Go
🌊 DOM Flood	DevTools → Performance → Rendering	Repaints constants, FPS instable
📡 Fetch Flood	DevTools → Network	200 req/s, barres "Queueing" longues