Guide de démarrage

5 étapes pour maîtriser le simulateur.

Ajouter des composants

Ouvrez le panneau de composants à gauche (bouton RACK dans le header). Les composants sont organisés en 7 catégories :

SimulationInfrastructureDonnéesRésilienceComputeCloudZones

Glissez un composant depuis le panneau et déposez-le sur le canvas.

Connecter les composants

Chaque composant possède des handles (points de connexion) sur ses bords. Cliquez sur un handle de sortie et tirez vers un handle d'entrée d'un autre composant.

Les connexions définissent le flux des requêtes pendant la simulation. Vous pouvez reconnecter une arête en tirant son extrémité vers un autre composant.

Configurer les propriétés

Cliquez sur un composant pour ouvrir le panneau de propriétés à droite. Chaque type a ses propres paramètres : latence, taux d'erreur, algorithme de répartition, politique d'éviction du cache, etc.

Les modifications sont sauvegardées automatiquement dans localStorage.

Lancer la simulation

Basculez en mode SIM via le toggle dans le header. Les contrôles apparaissent : Play, Pause, Stop, Reset. Choisissez une durée ou laissez en mode infini.

Le moteur PixiJS WebGL rend des particules GPU pour visualiser le flux des requêtes et réponses. Les composants changent de couleur selon leur état.

Analyser les résultats

La barre de télémétrie en bas affiche les métriques en temps réel. Cliquez dessus pour développer les détails :

Metrics— Latences, groupes de clients, utilisation serveurs

Output— Logs d'événements en temps réel

Bottlenecks— Détection automatique des goulots d'étranglement

Traces— Tracing distribué avec vue waterfall du chemin critique

Analytics— Métriques détaillées par composant avec synthèse post-simulation

Éditeur YAML

Définissez votre architecture en YAML — importez, exportez, versionnez. Une alternative puissante au drag & drop.

Structure du fichier

Un fichier YAML d'architecture contient 4 sections principales :

Structure de base

version: 1
name: "Mon Architecture"

zones:        # Optionnel — zones réseau
  backend:
    type: backend
    domain: "api.example.com"

components:   # Requis — vos composants
  clients:
    type: client-group
    config:
      virtualClients: 50

  server:
    type: http-server
    zone: backend
    config:
      port: 8080

connections:  # Requis — liens entre composants
  - from: clients
    to: server

version— Toujours 1

name— Nom libre de votre architecture

zones— Optionnel. Groupes logiques de composants

components— Requis. La clé = identifiant unique du composant

connections— Requis. Liste de liens from → to

Zones réseau

Les zones regroupent visuellement les composants. Un composant peut appartenir à une zone via la propriété zone.

Exemple de zones

zones:
  frontend:
    type: frontend        # frontend | backend | dmz | database | external
    domain: "app.example.com"
    subdomains:
      - "cdn.example.com"
    interZoneLatency: 5   # Latence inter-zone en ms
    position: { x: 50, y: 50 }
    size: { width: 400, height: 300 }

Types disponibles : frontend, backend, dmz, database, external

Composants

Chaque composant a un type et un bloc config optionnel. Si config est omis, les valeurs par défaut sont utilisées.

Exemples de composants

components:
  # Groupe de clients virtuels
  load-test:
    type: client-group
    config:
      label: "Load Test"
      virtualClients: 200
      rampUpTime: 5000
      distribution: uniform   # uniform | normal | burst

  # Serveur HTTP avec ressources
  api:
    type: http-server
    zone: backend             # Rattaché à la zone "backend"
    config:
      label: "API Server"
      port: 8080
      responseDelay: 50
      errorRate: 0.01

  # Base de données
  db:
    type: database
    zone: backend
    config:
      label: "PostgreSQL"
      maxConnections: 100
      queryDelay: 10

  # Load balancer
  lb:
    type: load-balancer
    config:
      algorithm: round-robin  # round-robin | least-connections | random

Type YAML	Composant
`http-client`	Client HTTP
`http-server`	Serveur HTTP
`client-group`	Groupe de clients
`api-gateway`	API Gateway
`load-balancer`	Load Balancer
`database`	Base de données
`cache`	Cache
`message-queue`	File de messages
`circuit-breaker`	Circuit Breaker
`cdn`	CDN
`waf`	WAF
`firewall`	Firewall
`serverless`	Serverless
`container`	Container
`service-discovery`	Service Discovery
`dns`	DNS
`cloud-storage`	Cloud Storage
`cloud-function`	Cloud Function
`host-server`	Serveur Hôte
`api-service`	API Service
`background-job`	Background Job
`identity-provider`	Identity Provider
`network-zone`	Zone Réseau

Connexions

Les connexions définissent le flux de données entre composants. Utilisez l'identifiant du composant (la clé dans components).

Exemple de connexions

connections:
  - from: load-test    # ID du composant source
    to: lb             # ID du composant cible

  - from: lb
    to: api

  - from: api
    to: db

Utiliser l'éditeur

L'éditeur YAML est accessible depuis la barre d'outils du simulateur (bouton YAML).

EXPORTER|Charge l'architecture actuelle du canvas dans l'éditeur en YAML

APPLIQUER|Parse le YAML et remplace l'architecture sur le canvas

.YAML|Télécharge le contenu en fichier .yaml

COPIER|Copie le contenu dans le presse-papier

CHARGER|Importe un fichier .yaml depuis le disque

Astuce : Exportez votre architecture, modifiez le YAML, puis appliquez pour itérer rapidement. Les fichiers .yaml sont compatibles Git pour le versioning.

Catalogue des composants

22 types de composants répartis en 8 catégories. Chaque composant est configurable via le panneau de propriétés.

Templates d'architecture

8 architectures pré-configurées accessibles depuis le menu TPL dans le header.

Monolithe Simple

Architecture monolithique classique avec cache-aside pattern.

Client GroupServeurCacheDatabase

client-grouphttp-servercachedatabase

Cas d'usage

Application web classique avec un seul serveur et une base de données. Le cache Redis réduit la charge sur la DB.

Load Balanced

Architecture avec répartition de charge entre plusieurs serveurs.

Client GroupLoad Balancer2x ServeurDatabase

client-groupload-balancerhttp-serverdatabase

Cas d'usage

Application à fort trafic nécessitant la répartition de charge. Testez l'impact des algorithmes (Round Robin, Least Connections).

Microservices

Architecture microservices avec API Gateway comme point d'entrée.

Client GroupAPI Gateway2x ServiceDatabase

client-groupapi-gatewayhttp-serverdatabase

Cas d'usage

Architecture distribuée avec routage par chemin. Testez le rate limiting et l'authentification.

Event-Driven

Architecture event-driven avec communication asynchrone via Message Queue.

Client GroupServeurMessage Queue2x ConsumerDatabase

client-grouphttp-servermessage-queuedatabase

Cas d'usage

Système découplé avec traitement asynchrone. Le producteur répond immédiatement, les consommateurs traitent en arrière-plan.

E-Commerce Microservices

Plateforme e-commerce avec zones réseau, microservices et communication asynchrone.

Client GroupWAFLB6x MicroservicesDB + Cache + MQ

client-groupwafload-balancernetwork-zoneapi-gatewayservice-discoverymessage-queuedatabasecache

Cas d'usage

Architecture e-commerce complète avec séparation en zones (DMZ, Backend, Données). Testez la résilience, le scaling et la communication inter-services.

Référence métriques

Les métriques collectées pendant la simulation et comment les interpréter.

Métriques globales

Métriques affichées dans la barre de télémétrie pendant la simulation.

Métrique	Description	Interprétation
REQ	Requêtes envoyées	Volume total de trafic généré par les clients. Augmente linéairement en charge constante.
RES	Réponses reçues	Total des réponses (succès + erreurs). L'écart avec REQ = requêtes encore en transit.
ERR (%)	Taux d'erreur	< 1% acceptable \| 1-5% à surveiller \| > 5% problème systémique. Inclut les rejets et erreurs serveur.
P50	Latence médiane	La moitié des requêtes sont plus rapides que ce seuil. Bon indicateur de la latence « typique ».
P95	Latence 95e percentile	95% des requêtes sont sous ce seuil. Indicateur clé pour les SLA. L'écart P50/P95 révèle la variabilité.
P99	Latence 99e percentile	Cas limite — révèle les pics de latence sous charge. Un P99 élevé indique des congestions intermittentes.
RPS	Requêtes par seconde	Débit réel du système. Comparez avec le débit attendu (virtualClients / baseInterval).
CPU %	Utilisation CPU	< 70% sain \| 70-90% attention \| > 90% saturation. Surveillez par serveur pour identifier les goulots.
RAM %	Utilisation mémoire	Mêmes seuils que CPU. Croissance continue = risque de fuite mémoire ou dimensionnement insuffisant.
Réseau %	Utilisation réseau	Bande passante relative au max configuré. Rarement limitant sauf pour les gros payloads.
Rejections	Requêtes rejetées	Capacité dépassée. Consultez rejectionsByReason pour identifier la cause (rate-limit, capacity, circuit-open, etc.).
Queue	Requêtes en file	Indique du backpressure. Croissance continue = serveurs sous-dimensionnés.

Seuils

Sain< 70%

Attention70-90%

Critique> 90%

Raisons de rejet

Lorsqu'une requête est rejetée, une raison est enregistrée dans les métriques. Voici les raisons possibles et comment les résoudre.

Raison	Description	Composants	Solution
`rate-limit`	Requête bloquée par le rate limiter de l'API Gateway	API Gateway	Augmentez rateLimiting.requestsPerSecond ou burstSize.
`capacity`	Capacité du serveur dépassée (connexions max + file pleine)	HTTP Server, Database, Serverless	Augmentez maxConcurrent/queueSize ou ajoutez des serveurs.
`circuit-open`	Circuit Breaker en état ouvert — protège le service en aval	Circuit Breaker	Corrigez le service défaillant en aval. Ajustez failureThreshold/timeout.
`auth-failure`	Authentification échouée (token expiré, clé invalide)	API Gateway	Vérifiez authType et authFailureRate. Réduisez le taux si trop élevé.
`waf-blocked`	Requête bloquée par le Web Application Firewall	WAF	Ajustez blockRate. Vérifiez les règles de sécurité activées.
`firewall-blocked`	Requête bloquée par le firewall réseau	Firewall	Vérifiez defaultAction et allowedPorts. Retirez l'IP des blockedIPs.
`timeout`	Requête expirée (délai de connexion dépassé)	HTTP Server, API Gateway	Augmentez connectionTimeoutMs ou réduisez la charge.
`oom-killed`	Container tué pour dépassement de la limite mémoire	Container	Augmentez memoryLimitMB ou optimisez la consommation mémoire.
`dns-failure`	Résolution DNS échouée	DNS	Vérifiez les enregistrements DNS et le failover.
`queue-full`	File de messages pleine, message rejeté	Message Queue	Augmentez maxQueueSize ou ajoutez des consumers.

Guide d'interprétation

Comment lire un graphique RPS vs latence

Le RPS (requêtes par seconde) et la latence sont inversement corrélés sous charge. Quand le RPS augmente, la latence reste stable jusqu'à un point d'inflexion où les ressources saturent. Au-delà, la latence augmente exponentiellement tandis que le RPS plafonne ou diminue. Ce point d'inflexion représente la capacité maximale soutenable du système.

Identifier les goulots d'étranglement

Utilisez la métrique Saturation % de chaque serveur pour identifier la ressource limitante. La saturation correspond au maximum de CPU, mémoire et réseau. La première ressource à atteindre 100% est le goulot d'étranglement. Surveillez aussi la file d'attente : une croissance continue indique que le serveur ne peut pas absorber le trafic entrant.

Patterns typiques

Croissance linéaire — La latence augmente proportionnellement à la charge. Comportement sain avec dégradation linéaire. Le système scale prévisiblement.

Courbe en J — La latence reste basse puis explose soudainement. Typique de la dégradation quadratique ou exponentielle. Le point d'inflexion indique la capacité maximale.

Plateau + effondrement — Le RPS plafonne puis chute brusquement. Les rejets augmentent. Le système est au-delà de sa capacité et commence à refuser du trafic.

Connexions (Edges)

Les edges relient les composants et définissent le flux des requêtes. Chaque edge est configurable via un clic.

Propriétés des edges

Cliquez sur un edge pour ouvrir son panneau de configuration. Chaque edge possède les propriétés suivantes.

Propriété	Type	Défaut	Description
protocol	enum	auto	Protocole de communication. « rest » : API RESTful HTTP/JSON. « grpc » : RPC binaire haute performance (HTTP/2, protobuf). « websocket » : connexion bidirectionnelle persistante. « graphql » : requêtes flexibles avec schéma. Auto-suggéré selon les composants connectés. Certains composants (database, cache, message-queue, background-job) utilisent une connexion directe sans protocole.
targetPort	number	—	Port cible sur le nœud de destination. OBLIGATOIRE pour les edges vers un Host Server — détermine quel conteneur enfant reçoit le trafic via les portMappings. Recommandé pour les edges vers un Firewall. Plage : 1-65535.
label	string	—	Texte affiché sur l'edge. Par défaut, affiche le protocole et le nombre de particules en transit. Utile pour documenter la connexion (ex: « auth », « data sync »).
color	string	auto	Couleur personnalisée en hexadécimal. 6 couleurs prédéfinies : gris (#888888), bleu (#3b82f6), vert (#22c55e), orange (#f97316), rouge (#ef4444), violet (#8b5cf6). Utile pour distinguer les flux (rouge=erreurs, vert=succès).
strokeWidth	number	1.5	Épaisseur en pixels (1-8). Augmentez pour mettre en évidence les flux critiques. Les edges sélectionnés passent à 2px avec un effet de brillance.
strokeStyle	enum	solid	Style du trait. « solid » : continu (standard). « dashed » : pointillés (connexions optionnelles). « dotted » : points (connexions logiques ou futures).
pathType	enum	bezier	Type de courbe. « bezier » : courbe élégante automatique (défaut). « smoothstep » : angle arrondi en escalier. « straight » : ligne droite.

Matrice des protocoles

Chaque type de composant supporte un ensemble de protocoles. Les composants de stockage (database, cache, message-queue) utilisent une connexion directe sans protocole applicatif.

Type composant	Protocoles supportés
Client HTTP	restgraphqlwebsocket
Serveur HTTP	restgraphqlwebsocket
Groupe de clients	restgraphqlwebsocket
API Gateway	restgrpcgraphqlwebsocket
Load Balancer	restgrpcwebsocket
Circuit Breaker	restgrpcgraphqlwebsocket
CDN	rest
WAF	restgraphqlwebsocket
Firewall	restgrpcgraphqlwebsocket
DNS	rest
Service Discovery	restgrpc
Serverless	restgrpc
Cloud Function	restgrpc
Cloud Storage	rest
Serveur Hôte	restgrpcgraphqlwebsocket
Container	restgrpcgraphqlwebsocket
API Service	restgrpcgraphql
Base de données	Connexion directe
Cache	Connexion directe
File de messages	Connexion directe
Background Job	Connexion directe
Identity Provider	rest
Zone Réseau	Connexion directe

Particules animées

Pendant la simulation, des particules animées circulent le long des edges pour visualiser le flux de requêtes et réponses.

RequêteParticule bleue — requête en transit du client vers le serveur.

Réponse succèsParticule verte — réponse réussie du serveur vers le client.

Réponse erreurParticule rouge — réponse en erreur retournée au client.

Tracing distribué

Le simulateur trace chaque requête bout-en-bout à travers tous les composants traversés, générant des spans et des analyses de chemin critique.

Concepts clés

Span

Unité de travail atomique représentant le passage d'une requête dans un composant. Chaque composant traversé génère un span avec son temps de traitement, son statut et sa relation parent.

Trace (chaîne)

Ensemble de spans liés par un chainId commun, représentant le parcours complet d'une requête à travers l'architecture. La trace commence au client et se termine quand la réponse revient.

Chemin critique

Séquence de spans qui détermine la durée totale de la trace. Optimiser le chemin critique réduit directement la latence bout-en-bout.

Goulot d'étranglement (bottleneck)

Le span le plus long du chemin critique. Si un span database prend 80% du temps total, c'est le goulot. Il est mis en évidence visuellement dans le waterfall avec une icône d'alerte.

Pattern N+1

Anti-pattern où un composant est appelé N fois en série (ex: une requête DB par élément d'une liste au lieu d'un batch). Détecté automatiquement quand un même nœud apparaît 3+ fois dans une trace.

Waterfall

Visualisation horizontale de la trace où chaque span est représenté par une barre dont la position (gauche) indique le moment de début et la largeur indique la durée. Permet de voir le parallélisme et les dépendances.

Interface TraceSpan

Unité de travail atomique — un span est créé à chaque traversée d'un composant par une requête.

Champ	Type	Description
id	string	Identifiant unique du span, généré automatiquement.
chainId	string	Identifiant de la chaîne de requêtes à laquelle appartient ce span. Tous les spans d'une même requête bout-en-bout partagent le même chainId.
nodeId	string	Identifiant du nœud (composant) qui a traité cette étape de la requête.
nodeName	string	Nom lisible du composant affiché dans le waterfall.
nodeType	string	Type du composant (http-server, database, cache…). Détermine la couleur de la barre dans le waterfall.
parentSpanId	string	Référence au span parent dans l'arbre d'appels. Permet de reconstruire la hiérarchie des appels.
startTime	number	Timestamp de début du traitement (en ms depuis le début de la simulation).
endTime	number	Timestamp de fin du traitement. Absent si le span est encore actif.
duration	number	Durée totale du span (endTime − startTime). Calculée automatiquement à la fin du traitement.
status	enum	État du span : « active » (en cours), « completed » (succès), « error » (échec). Les spans en erreur apparaissent en rouge dans le waterfall.

Interface RequestTrace

Trace complète regroupant tous les spans d'une chaîne de requêtes. Représente le parcours bout-en-bout.

Champ	Type	Description
chainId	string	Identifiant unique de la trace complète, partagé par tous les spans de la chaîne.
spans	object	Liste ordonnée de tous les TraceSpan de cette chaîne. Chaque span représente le passage de la requête dans un composant.
totalDuration	number	Durée totale de la trace (du premier startTime au dernier endTime). C'est le temps bout-en-bout perçu par le client.
startTime	number	Timestamp du début de la trace (= startTime du premier span).
endTime	number	Timestamp de fin de la trace (= endTime du dernier span complété).
status	enum	État global : « completed » si tous les spans ont réussi, « error » si au moins un span a échoué, « active » si des spans sont encore en cours.

Interface CriticalPathAnalysis

Analyse automatique du chemin critique, détection des goulots d'étranglement et des patterns N+1.

Champ	Type	Description
bottleneckSpan	object	Le span ayant la plus grande durée dans la trace. Représente le goulot d'étranglement principal. Affiché avec une icône d'alerte et un contour orange dans le waterfall.
timePerComponent	object	Répartition du temps par composant : nodeId, nodeName, nodeType, totalTime (ms) et percentage (%). Permet d'identifier quels composants consomment le plus de temps.
nPlusOnePatterns	object	Détection des patterns N+1 : lorsqu'un même composant (ex: database) est appelé plus de 2 fois dans une même trace, il est signalé comme un pattern N+1 potentiel. Inclut nodeId, nodeName et count.
totalDuration	number	Durée totale du chemin critique (peut différer de la durée totale de la trace si des appels sont parallèles).

Guide du Waterfall

Lecture du waterfall

L'axe horizontal représente le temps. Chaque ligne est un span. La longueur de la barre = durée du traitement. Les barres décalées vers la droite ont commencé plus tard. Des barres superposées verticalement = traitements parallèles.

Couleurs des barres

Chaque type de composant a sa couleur (bleu = client/serveur, violet = gateway, ambre = database, vert = cache, orange = message queue, rouge = circuit breaker). Les spans en erreur sont toujours rouges.

Sélection et navigation

Cliquez sur une trace dans la liste de gauche pour voir son waterfall détaillé. Cliquez sur un span pour sélectionner le composant correspondant dans le canvas et voir ses propriétés.

Répartition du temps

Sous le waterfall, la section « Time breakdown » montre le pourcentage de temps passé dans chaque composant. Un composant à 60%+ du temps total est un candidat prioritaire à l'optimisation.

Alertes N+1

Les patterns N+1 détectés sont affichés avec une icône d'alerte orange. Par exemple : « database appelée 5x » indique qu'il faudrait grouper ces appels en un seul (batch/join).

Filtrage

La barre de recherche filtre les traces par chainId ou par nom de nœud traversé. Utile pour retrouver les traces passant par un composant spécifique.

Erreurs de conception

Erreurs courantes dans la conception d'architectures et comment les corriger.

Connexions9

Erreur	Sévérité	Description	Solution
Source sans edge sortant	ERROR	Un HTTP Client ou Client Group n'a pas de destination configurée. Aucune requête ne sera envoyée.	Ajoutez une connexion (edge) vers un serveur, gateway ou load balancer.
Load Balancer sans backend	ERROR	Le load balancer n'a aucun serveur backend connecté en aval.	Connectez au moins un HTTP Server en sortie du load balancer.
Circuit Breaker incomplet	ERROR	Le circuit breaker doit avoir des connexions entrante ET sortante pour fonctionner.	Placez-le entre un client/gateway (entrée) et un service fragile (sortie).
Cache sans fallback DB	WARNING	Le cache n'a pas de base de données connectée en aval pour les cache miss.	Connectez une base de données en sortie pour le pattern cache-aside.
CDN sans origin	WARNING	Le CDN avec un hit ratio < 100% n'a pas de serveur d'origine pour les cache miss.	Connectez un HTTP Server en aval comme serveur d'origine.
Load Balancer à 1 backend	INFO	Un load balancer avec un seul backend ne répartit pas la charge.	Ajoutez d'autres serveurs ou supprimez le load balancer.
Message Queue sans consumer	WARNING	La file n'a aucun service consommateur connecté. Les messages s'accumuleront.	Connectez un service ou Background Job en aval.
Nœud isolé	WARNING	Le composant n'a aucune connexion entrante ou sortante.	Connectez-le au flux de requêtes ou supprimez-le s'il est inutile.
Edge invalide (dangling)	ERROR	L'edge référence un nœud source ou cible qui n'existe plus.	Supprimez l'edge invalide.

Ports4

Erreur	Sévérité	Description	Solution
Edge → Host Server sans targetPort	ERROR	Les edges vers un Host Server doivent spécifier un targetPort pour router vers les conteneurs internes.	Configurez targetPort dans les propriétés de l'edge (clic sur l'edge).
Edge → Firewall sans targetPort	WARNING	Il est recommandé de spécifier un targetPort pour les edges vers un Firewall.	Ajoutez le port dans les propriétés de l'edge.
Port non résolu	ERROR	Le targetPort de l'edge ne correspond à aucun portMapping du Host Server.	Vérifiez les port mappings du serveur hôte et corrigez le targetPort.
Port mapping orphelin	ERROR	Un port mapping référence un conteneur qui n'existe pas ou n'est pas enfant du Host Server.	Corrigez le containerNodeId dans les port mappings.

Routage4

Erreur	Sévérité	Description	Solution
Gateway avec routes sans edges	WARNING	L'API Gateway a des règles de routage mais aucune connexion vers les services cibles.	Connectez les services référencés dans les routeRules.
Route vers service non connecté	WARNING	Une règle de routage référence un targetServiceName qui n'est pas connecté à la gateway.	Connectez le service correspondant ou supprimez la règle orpheline.
Priorités dupliquées	WARNING	Plusieurs règles de routage ont la même priorité, causant un routage imprévisible.	Assignez des priorités uniques à chaque règle.
API Service sans serviceName	WARNING	Le service n'a pas de nom unique configuré, rendant le routage par API Gateway impossible.	Définissez un serviceName unique.

Ressources3

Erreur	Sévérité	Description	Solution
Surcharge client → serveur	WARNING	Le groupe de clients génère plus de trafic que le serveur cible peut supporter (virtualClients > maxConcurrent).	Augmentez la capacité du serveur ou réduisez le nombre de clients.
processingTime = 0	INFO	Le temps de traitement CPU est à 0ms (traitement instantané). La charge CPU ne sera pas simulée.	Ajoutez un temps de traitement réaliste (10-100ms) si vous souhaitez simuler la charge.
Mémoire insuffisante prévisible	WARNING	memoryPerRequestMB × maxConcurrent + baseUsageMB > totalMB. Le serveur manquera de mémoire sous charge maximale.	Augmentez totalMB ou réduisez memoryPerRequestMB.

Champs obligatoires3

Erreur	Sévérité	Description	Solution
HTTP Server sans resources	ERROR	Le serveur HTTP n'a pas de configuration de ressources.	Configurez CPU, mémoire, réseau et connexions dans le panneau de propriétés.
Database sans performance	ERROR	La base de données n'a pas de latences configurées.	Configurez readLatencyMs, writeLatencyMs et transactionLatencyMs.
Cache sans configuration	ERROR	Le cache n'a pas de configuration mémoire ni de politique d'éviction.	Configurez maxMemoryMB, defaultTTLSeconds et evictionPolicy.

Configuration8

Erreur	Sévérité	Description	Solution
Serverless timeout < coldStart	ERROR	Le timeout est inférieur au temps de cold start. La fonction timeout systématiquement au démarrage à froid.	Augmentez timeoutMs au-dessus de coldStartMs.
Serverless min > max instances	ERROR	Le minimum d'instances est supérieur au maximum. Configuration invalide.	Corrigez : minInstances doit être ≤ maxInstances.
Serverless concurrency = 0	ERROR	La concurrence est à 0, aucune requête ne sera traitée.	Définissez concurrencyLimit > 0.
Cron sans schedule	ERROR	Un job de type « cron » n'a pas d'expression cron configurée.	Définissez schedule (ex: « 0/5 * * * * » = toutes les 5 min).
Batch sans batchSize	ERROR	Un job de type « batch » n'a pas de taille de lot configurée.	Définissez batchSize.
virtualClients ≤ 0	ERROR	Le nombre de clients virtuels doit être positif (1-1000).	Définissez un nombre entre 1 et 1000.
errorRate > 80%	WARNING	Un taux d'erreur supérieur à 80% rend le service quasi inutilisable.	Vérifiez si c'est intentionnel (chaos testing) ou une erreur de configuration.
CB timeout < 5000ms	INFO	Un timeout très court peut causer des oscillations fréquentes open/half-open.	Envisagez un timeout de 10s+ pour laisser le temps au service de se rétablir.

Hiérarchie2

Erreur	Sévérité	Description	Solution
Container sans Host Server	ERROR	Un conteneur doit être placé dans un Host Server.	Faites glisser le conteneur dans un Host Server existant.
Port mapping vers non-enfant	ERROR	Un port mapping du Host Server référence un conteneur qui n'est pas son enfant direct.	Vérifiez que le conteneur cible est placé dans le Host Server.

Guide de démarrage

Ajouter des composants

Connecter les composants

Configurer les propriétés

Lancer la simulation

Analyser les résultats

Éditeur YAML

Structure du fichier

Zones réseau

Composants

Connexions

Utiliser l'éditeur

Catalogue des composants

Client HTTP

Serveur HTTP

Groupe de clients

API Gateway

Load Balancer

CDN

WAF

Firewall

Service Discovery

Base de données

Cache

File de messages

Circuit Breaker

Serveur Hôte

Container

API Service

Serverless

Background Job

Cloud Storage

Cloud Function

Identity Provider

Zone Réseau

Templates d'architecture

Monolithe Simple

Load Balanced

Microservices

Event-Driven

E-Commerce Microservices

Référence métriques

Métriques globales

Raisons de rejet

Guide d'interprétation

Comment lire un graphique RPS vs latence

Identifier les goulots d'étranglement

Patterns typiques

Connexions (Edges)

Propriétés des edges

Matrice des protocoles

Particules animées

Tracing distribué

Concepts clés

Span

Trace (chaîne)

Chemin critique

Goulot d'étranglement (bottleneck)

Pattern N+1

Waterfall

Interface TraceSpan

Interface RequestTrace

Interface CriticalPathAnalysis

Guide du Waterfall

Lecture du waterfall

Couleurs des barres

Sélection et navigation

Répartition du temps

Alertes N+1

Filtrage

Erreurs de conception

Connexions9

Ports4

Routage4

Ressources3

Champs obligatoires3

Configuration8

Hiérarchie2