Tests de charge — Guide utilisateur | YoBench

À quoi sert le module « Tests de charge »

Le module génère de la charge sur vos services web pour observer leur comportement sous trafic. Deux modes : HTTP via undici dans des worker threads (jusqu'à 500 threads concurrents) et navigateur via Chromium (jusqu'à 20 onglets concurrents). Les métriques se mettent à jour chaque seconde — RPS, latence, P95/P99, taux d'erreur et threads actifs.

Ce que vous obtenez :

• Forte parallélisation HTTP — jusqu'à 500 threads sur une machine, sans navigateur, overhead minimal.
• Mode navigateur — jusqu'à 20 onglets Chromium concurrents avec page.goto() et waitUntil: networkidle2, pour des contrôles de rendu complet.
• Ramp-up — montée progressive des threads (ramp_step_threads threads toutes les ramp_step_duration secondes).
• Métriques temps réel — un snapshot par seconde dans load_test_snapshots : RPS, latence moyenne, P95/P99, taux d'erreur, threads actifs.
• Proxy et auth — en-têtes/cookies/paramètres de query appliqués à chaque requête.
• Résultats persistés — modèles et rapports stockés localement.

Paramètres du test

À la création d'un modèle :

• URL — obligatoire.
• Méthode HTTP — GET uniquement pour l'instant (codé en dur dans le worker).
• En-têtes — depuis le profil d'auth choisi (méthode header).
• Cookies — depuis le profil d'auth (méthode cookie) ; injectés dans l'en-tête Cookie.
• Threads — 1–500 pour HTTP, 1–20 pour navigateur.
• Durée — minimum 5 secondes.
• Ramp-up — ramp_enabled, ramp_step_duration (sec), ramp_step_threads (threads ajoutés par étape). Disponible uniquement en mode HTTP ; le mode navigateur démarre toujours avec tous les threads.
• Proxy — IP aléatoire depuis le groupe de proxy choisi ; auth supportée.
• Profil d'auth — entrée partagée des réglages.

Un seul test tourne à la fois — pour la précision des mesures.

Métriques temps réel

Les snapshots sont sauvegardés chaque seconde dans load_test_snapshots :

• RPS — requêtes par seconde dans la fenêtre récente.
• Avg latency — temps de réponse moyen (ms).
• P95 / P99 — percentiles 95 / 99 de latence.
• Taux d'erreur — pourcentage de réponses en échec.
• Threads actifs — threads en cours (croît pendant le ramp-up).
• Requêtes / erreurs totales — compteurs cumulés.

Le rapport final inclut aussi P50 (médiane), Min et Max de latence.

Limites de mémoire pour les samples de latence : HTTP — 50 000 derniers, navigateur — 10 000.

Réglages globaux

Pas de clés loadTesting* dédiées dans les réglages centraux — tous les paramètres dans les modèles (load_test_templates) et rapports (load_test_reports).

Flux d'utilisation

1. Créez un modèle

1. Ouvrez le module Tests de charge depuis le menu de gauche.
2. Sur Modèles cliquez sur Créer un modèle.
3. Renseignez URL, mode (HTTP / Navigateur), nombre de threads, durée.
4. Optionnellement activez le ramp-up et fixez les étapes.
5. Choisissez un groupe de proxy et un profil d'auth.
6. Enregistrez.

2. Lancez un test

Le bouton Lancer à côté du modèle crée un rapport en running. Un seul test à la fois. Stop termine en avance ; les métriques sont conservées.

3. Examinez le rapport

Sur l'onglet Rapports, chaque entrée a des graphiques (RPS, latence, P95/P99, erreurs), des nombres de synthèse et la liste seconde par seconde des snapshots.

4. Comparez les runs

Utilisez les rapports pour comparer entre changements de code / proxy / environnement. Relancez un modèle autant que nécessaire — chaque run produit son propre rapport.

Étapes suivantes

• Pendant le test, surveillez le back-end via Serveurs et Health Check.
• Utilisez Site Audit pour le SEO et Lighthouse en charge normale.
• Pour une vérification de pipeline JS complète, choisissez Navigateur (limité à 20 threads).

Aide et retour

Vous voulez POST/PUT/DELETE, des corps de requête, des données randomisées ou de la charge WebSocket ? Contactez-nous via le formulaire de retour.