09 - Glossaire
Ce que tu vas trouver ici
Tous les termes techniques utilises dans cette serie, classes par ordre alphabetique. Chaque terme a une définition courte et un renvoi vers l'article ou il est détaillé. Reviens ici quand tu croises un mot inconnu.
Prerequisites
Ce glossaire est conçu pour etre consulte a tout moment. Il est plus utile apres avoir parcouru les articles précédents.
Autocannon
Outil de benchmark HTTP écrit en Node.js par Matteo Collina. Tres simple d'utilisation : une commande, une URL, et tu as les latences et le throughput. Pas de scénarios complexes, mais imbattable pour un test rapide.
Voir article 08.
Benchmark
Mesure des performances d'un bout de code isole (une fonction, un algorithme). On exécuté le code des centaines ou milliers de fois et on collecte les statistiques (temps moyen, mediane, percentiles). En TypeScript avec Bun, on utilise performance.now() pour les mesures de temps. benchmark.paltemps.fr automatise ce processus.
Voir article 01.
Breakpoint (point de rupture)
Le moment ou un système sous charge passe de "ca ralentit" a "ca casse". La latence explose, les erreurs apparaissent, le throughput chute. Connaitre son breakpoint permet de dimensionner sa marge de sécurité.
Voir article 04.
Cache hit ratio
Le pourcentage de requêtes servies par le cache plutot que par la source de donnees (base, API, disque). Un ratio de 95% signifie que seulement 5% des requêtes atteignent la source. Plus c'est haut, moins la source est sollicitee sous charge.
Circuit breaker
Pattern de resilience. Quand un service externe accumule les erreurs, le circuit breaker "ouvre le circuit" et refuse les requêtes immédiatement au lieu de les envoyer vers un service mort. Apres un delai, il laisse passer une requête test pour vérifier si le service est revenu.
Voir article 06.
Connection pool
Un ensemble preinitialisee de connexions vers une base de donnees ou un service. Au lieu d'ouvrir et fermer une connexion a chaque requête (coûteux), on pioche dans le pool. PostgreSQL a un max_connections de 100 par défaut, et les pools applicatifs reservent généralement 10 a 30 connexions.
Voir article 04 et article 07.
CPU bound
Un traitement limite par la puissance du processeur. JSON.parse() sur un gros payload, chiffrement, compression, calculs mathematiques. Contraste avec I/O bound. Quand le CPU est a 100%, ajouter plus de requêtes ne fait que ralentir tout le monde.
Endurance test
Synonyme de soak test. Test de charge sur une longue duree (heures) a une charge moderee pour détecter les degradations progressives.
Voir article 07.
Error rate (taux d'erreur)
Le pourcentage de requêtes qui echouent (HTTP 5xx, timeouts, connexions refusees). En dessous de 0.1% en conditions normales, c'est acceptable. Au-dessus de 1%, il y a un problème. En stress test, on observe a quel niveau de charge le taux d'erreur commence a monter.
GC (Garbage Collection)
Le processus automatique par lequel le runtime JavaScript libéré la mémoire des objets qui ne sont plus références. Un GC sain créé un pattern en dents de scie dans la consommation mémoire. Un GC qui ne libéré rien indique une fuite mémoire.
Voir article 05.
Heap
La zone de mémoire ou JavaScript stocke les objets et les donnees dynamiques. process.memoryUsage().heapUsed indique combien de heap est actuellement occupee. C'est cette valeur qui revele les fuites mémoire quand elle monte sans redescendre.
Voir article 01 et article 05.
Hot path
Le chemin d'exécution le plus fréquemment emprunte dans ton code. Si une fonction est appelee 10 000 fois par seconde, c'est un hot path. Optimiser un hot path a un impact énorme. Optimiser du code appele une fois par heure n'a aucun impact mesurable.
I/O bound
Un traitement limite par les entrees/sorties : requêtes réseau, acces disque, requêtes base de donnees. La plupart des APIs web sont I/O bound. Le CPU attend que le réseau ou le disque reponde. Ajouter du CPU ne change rien, il faut optimiser les I/O (cache, connexions persistantes, requêtes plus efficaces).
Iteration
Dans k6, une itération est une exécution complète de la fonction export default. Un VU qui tourne pendant 30 secondes avec 1 seconde de sleep fait environ 30 itérations.
Voir article 02.
k6
Outil de test de charge open source développé par Grafana Labs. Ecrit en Go, scripts en JavaScript. Le binaire est autonome, les résultats sont lisibles dans le terminal, et les thresholds permettent l'intégration CI/CD. C'est l'outil principal de cette serie.
Voir article 02 et article 08.
Latence (latency)
Le temps entre l'envoi d'une requête et la reception de la réponse. Mesuree en millisecondes. La latence moyenne est trompeuse (elle cache les valeurs extremes), c'est pour ca qu'on utilise les percentiles (p50, p95, p99).
Voir article 00.
Load test (test de charge)
Simuler le trafic attendu en production pour vérifier que le système le supporte. Si tu attends 100 utilisateurs simultanes, tu en simules 100 pendant 10-15 minutes et tu verifies que la latence et le taux d'erreur restent acceptables.
Voir article 02 et article 03.
Memory leak (fuite mémoire)
De la mémoire allouee qui n'est jamais libérée. En JavaScript, ca arrive quand des objets restent références (event listeners oublies, closures, caches sans limite). Le heap grossit progressivement jusqu'a l'OOM kill.
Voir article 05.
p50 / p95 / p99 (percentiles)
p50 (mediane) : 50% des mesures sont en dessous. p95 : 95% des mesures sont en dessous. p99 : 99% des mesures sont en dessous. En tests de performance, le p95 est la metrique la plus courante pour mesurer la latence. Le p95 a 200ms signifie que 95% des requêtes repondent en moins de 200ms.
Voir article 00.
Peak load (charge maximale)
Le niveau de trafic le plus eleve que tu observes en production. Souvent a des heures spécifiques (9h-10h le matin, lundi apres le week-end). Ton système doit tenir le peak load sans degradation.
Profiling
L'analyse détaillée du comportement d'un programme en cours d'exécution. Profiling CPU : quelles fonctions prennent le plus de temps. Profiling mémoire : quels objets consomment le plus de RAM. Les heap snapshots de Chrome DevTools sont un outil de profiling mémoire.
Voir article 05.
QPS (Queries Per Second)
Nombre de requêtes traitees par seconde. Synonyme de throughput dans le contexte HTTP. Un serveur a 1 000 QPS traite 1 000 requêtes par seconde. La différence avec req/s : QPS est plutot utilise cote base de donnees, req/s cote HTTP.
Ramping
Augmentation progressive de la charge dans un test. Au lieu de démarrer directement a 100 VUs, tu montes de 0 a 100 sur 5 minutes. Ca permet de voir a quel palier la latence commence a degrader.
Voir article 03.
RSS (Resident Set Size)
La mémoire physique (RAM) réellement occupee par un process. C'est la valeur affichee dans htop ou docker stats. Le RSS inclut le heap JavaScript, la stack, les buffers natifs, et le code charge en mémoire.
Voir article 01 et article 05.
Saturation
L'état ou une ressource (CPU, mémoire, connexions, bande passante) est utilisee a 100% de sa capacité. Au-dela de la saturation, les nouvelles requêtes doivent attendre, ce qui augmente la latence. C'est le début de la cascade failure.
Scénario
Dans k6, un scénario definit un pattern de charge : combien de VUs, comment ils arrivent, combien de temps le test dure. Un test peut avoir plusieurs scénarios en parallèle (lecteurs + ecritures par exemple).
Voir article 03.
Smoke test
Un test de charge minimal : 1-2 VUs pendant 1 minute. L'objectif n'est pas de tester les performances mais de vérifier que le script fonctionne et que le serveur répond. A lancer avant un vrai test de charge pour éviter de perdre 30 minutes sur un script bugge.
Soak test (test d'endurance)
Test de charge a intensite moderee sur une longue duree (2 heures minimum, idealement 12-24 heures). L'objectif : détecter les fuites lentes (mémoire, connexions, file descriptors) et la degradation progressive des performances.
Voir article 07.
Spike test
Test qui simule un afflux soudain de trafic. On passe de 5 VUs a 100 en quelques secondes pour voir comment le système reagit. L'objectif : vérifier que le serveur absorbe le pic sans s'effondrer et qu'il revient a la normale ensuite.
Voir article 03.
Stress test
Test qui augmente la charge au-delà des limites attendues jusqu'a trouver le point de rupture. Contrairement au load test (qui vérifié que ca tient), le stress test cherche volontairement a casser le système.
Voir article 04.
Throughput (debit)
Le nombre de requêtes traitees par seconde (req/s). Avec le latence et le taux d'erreur, c'est une des trois metriques fondamentales des tests de performance. Un throughput qui plafonne pendant que la charge augmente indique la saturation.
Timeout
Le delai maximum d'attente pour une réponse. Sans timeout, une requête vers un serveur mort reste suspendue indefiniment. En TypeScript, on utilise AbortController avec setTimeout pour implementer des timeouts sur fetch().
Voir article 06.
Virtual user (VU)
Dans k6 et les outils de test de charge, un VU est une boucle d'exécution simulee. Chaque VU exécuté le script de test en boucle pendant toute la duree du test. 10 VUs avec 1 seconde de sleep generent environ 10 req/s.
Voir article 02.
Warmup
Phase de preparation avant les mesures d'un benchmark. En JavaScript, les premières executions d'une fonction sont interpretees. Apres un certain nombre d'appels, le JIT compiler optimise le code. Le warmup permet de mesurer le code optimise, pas le code interprète.
Voir article 01.
Article précédent : 08 - Comparatif : k6 vs Artillery vs Autocannon vs wrk