Glossaire LoadFocus
Définitions courtes des termes que vous rencontrez dans l'application et dans cette documentation, regroupés par produit. Chacun renvoie à la page qui le traite en détail.
Configuration des tests de charge
Section intitulée « Configuration des tests de charge »- Utilisateur virtuel (VU) : un utilisateur simulé qui envoie les requêtes de votre test l'une après l'autre pendant tout le test. Le nombre d'utilisateurs virtuels correspond au nombre de personnes que le test simule en même temps. Voir Que sont les utilisateurs virtuels dans les tests de charge.
- Générateur de charge : une machine dans le cloud qui exécute des utilisateurs virtuels et envoie leurs requêtes à votre site. Un test utilise un ou plusieurs générateurs de charge par emplacement. Voir Matériel des générateurs.
- Moteur (engine) : le nom que la page de résultats donne à un générateur de charge, comme dans "engine 2 peaked at 91% CPU" et dans l'onglet Santé du moteur des exécutions JMeter. Voir Saturation du générateur de charge.
- Temps de montée en charge : le temps que met le test pour passer de zéro au nombre total d'utilisateurs virtuels. Voir Qu'est-ce que le temps de montée en charge dans les tests de charge.
- Étapes de montée en charge : le nombre d'étapes par lesquelles les utilisateurs virtuels sont ajoutés pendant le temps de montée en charge. Plus d'étapes donnent une montée plus régulière. Voir Que sont les étapes de montée en charge dans les tests de charge.
- Délai : le Délai (ms) est la pause entre le démarrage d'un utilisateur virtuel et celui du suivant, pour qu'ils n'envoient pas tous leur première requête au même instant. Voir Qu'est-ce que le délai lors de l'exécution d'un test de charge ?.
- Durée : le temps pendant lequel le test envoie de la charge, en secondes. Voir Qu'est-ce que la durée dans les tests de charge.
- Itération : un passage d'un utilisateur virtuel par toutes les requêtes du test. Avec Exécuter par itérations plutôt que par durée, chaque utilisateur exécute un nombre fixe d'itérations. Dans les tests k6, les itérations sont partagées : les utilisateurs exécutent ce nombre d'itérations au total et démarrent tous ensemble. Voir Que sont les itérations dans les tests de charge ?.
- Emplacement : la région cloud dans laquelle tournent les générateurs de charge. Les forfaits payants peuvent choisir n'importe lequel des 25 emplacements. Voir Emplacement géographique des tests de charge.
- Planification : exécute un test automatiquement aux moments que vous choisissez et vous prévient par e-mail quand une exécution ne respecte pas ses seuils ou ne se termine pas. Voir Tests de charge planifiés.
- Seuil de réussite/échec : une limite, comme un temps de réponse ou un taux d'erreur maximal, qui marque automatiquement chaque exécution comme réussie ou échouée. Voir Seuils de réussite/échec.
- AI Credits : ce que consomment les analyses IA des résultats et Create with AI : 1 crédit par analyse. Chaque forfait en inclut un certain nombre par période glissante de 30 jours. Voir AI Credits.
Résultats des tests de charge
Section intitulée « Résultats des tests de charge »- Identifiant d'exécution de test : le numéro d'une exécution d'un test. Chaque exécution reçoit le numéro suivant pour ce nom de test, affiché comme Exécution dans l'onglet Vue d'ensemble. Voir Qu'est-ce qu'un identifiant d'exécution de test ?.
- Échantillon : une requête enregistrée par un générateur de charge, avec son temps de réponse et son résultat. Échantillons dans la vue d'ensemble est le nombre total de requêtes envoyées. Voir Que sont les échantillons dans les tests de charge ?.
- Hits/s : le nombre de requêtes que votre application reçoit chaque seconde. La vue d'ensemble affiche la moyenne de l'exécution. Voir Comment vérifier les résultats des tests de charge.
- Débit (throughput) : la quantité de travail que le test fait passer par seconde, comptée en requêtes (hits/s) ou en kilo-octets envoyés et reçus, comme dans l'onglet Analyses. Voir Informations sur les tests de charge.
- Percentile (P90, P95, P99) : le temps de réponse sous lequel se trouvent 90 %, 95 % ou 99 % des requêtes. Les percentiles montrent la traîne lente qu'une moyenne cache. Voir Décoder le temps de réponse moyen.
- Taux d'erreur : la part des requêtes en échec, avec une réponse 4xx ou 5xx ou une erreur de connexion. La vue d'ensemble l'affiche comme Erreurs %. Voir Erreurs par type et taux d'erreur.
- Référence (baseline) : une exécution que vous fixez comme point de comparaison. Six indicateurs principaux des autres exécutions affichent alors l'écart en pourcentage par rapport à elle. Voir Comparaison de référence entre les tests de charge.
Surveillance API
Section intitulée « Surveillance API »- Vérification : un test de votre API ou de votre site que LoadFocus exécute selon une planification depuis les emplacements choisis : API, multi-étapes, navigateur, DNS ou TCP. Voir Comment créer une nouvelle vérification API.
- Exécution de vérification : une exécution d'une vérification depuis un emplacement. Une vérification multi-étapes compte une exécution par étape. Les forfaits incluent un nombre d'exécutions de vérification par mois. Voir Forfaits et limites.
- Moniteur Heartbeat : un moniteur pour les tâches planifiées. Au lieu que LoadFocus appelle votre service, votre tâche appelle LoadFocus à chaque fois qu'elle se termine, et le moniteur passe à DOWN si l'appel n'arrive pas à temps. Voir Moniteurs Heartbeat (tâches cron).
- Canal d'alerte : l'endroit où les alertes sont envoyées : e-mail, Slack, Microsoft Teams, webhook, Discord, PagerDuty ou Opsgenie. Voir Canaux d'alerte.
- Fenêtre de maintenance : une plage horaire pendant laquelle les alertes sont mises en sourdine pour les vérifications choisies. Les vérifications continuent de s'exécuter et d'enregistrer des résultats. Voir Fenêtres de maintenance.
- Snippet : un morceau de JavaScript réutilisable que vous enregistrez une fois et chargez dans les scripts de vérification avec
require(). Voir Snippets. - Scripts de setup et de teardown : du JavaScript qui s'exécute une fois juste avant une vérification (setup) et une fois juste après (teardown), par exemple pour récupérer un jeton ou nettoyer des données de test. Voir Scripts de préparation et de nettoyage.
- SLO et SLA : un objectif SLO est la disponibilité que vous visez pour un moniteur, par exemple 99,9 %. Le rapport SLA est l'e-mail récurrent qui montre la disponibilité par rapport à cet objectif. Voir Rapports de disponibilité SLA & SLO.
- Budget d'erreur : le temps d'indisponibilité que votre objectif SLO autorise sur la période. Un objectif de 99,9 % sur 30 jours autorise environ 43 minutes. Quand le budget est épuisé, le SLO est dépassé. Voir Rapports de disponibilité SLA & SLO.
- Page de statut : une page publique qui affiche l'état actuel des moniteurs que vous choisissez. Voir Créez une page de statut publique pour vos moniteurs.
Surveillance de la vitesse des pages
Section intitulée « Surveillance de la vitesse des pages »- Test : dans la Surveillance de la vitesse des pages, une vérification basée sur Lighthouse d'une URL, depuis l'emplacement de votre choix, selon la planification que vous définissez. Voir Créer un nouveau test de performance de site web.
- Moniteur : la règle d'alerte que vous associez à un test Page Speed. Il vous prévient quand un score ou une métrique franchit la valeur fixée. Voir Créer une nouvelle alerte.
- Score Lighthouse : quatre scores de 0 à 100, Performance, Accessibility, Best Practices et SEO, qui résument chacun toute une catégorie de vérifications. Voir Métriques d'alerte.
- Core Web Vitals : les trois métriques avec lesquelles Google évalue l'expérience de page. Voir Que sont les Core Web Vitals ?.
- LCP (Largest Contentful Paint) : le temps que met le plus grand bloc de texte ou la plus grande image à s'afficher. Mesure le chargement.
- INP (Interaction to Next Paint) : le temps que met la page à répondre visuellement après un clic, un toucher ou une frappe au clavier. Mesure la réactivité.
- CLS (Cumulative Layout Shift) : l'ampleur du déplacement du contenu visible pendant le chargement de la page. Mesure la stabilité visuelle.
- Données de laboratoire et données de terrain : les données de laboratoire viennent d'une seule exécution contrôlée, comme un test Page Speed. Les données de terrain viennent de vrais visiteurs dans la durée, comme les 28 jours du Chrome UX Report ou vos propres données RUM. Voir Données de terrain réelles (CrUX).
- RUM (Real User Monitoring) : les Core Web Vitals mesurés dans les navigateurs des personnes qui visitent votre site, grâce à un petit script que vous ajoutez à vos pages. Voir Real User Monitoring (RUM).