Les tests de performance génèrent des métriques à plusieurs niveaux du système. Ce guide définit chaque métrique, explique sa méthode de mesure et fournit des seuils reconnus par l'industrie pour établir les critères de réussite ou d'échec.
Par où commencer
Si vous débutez dans les tests de performance ou si vous hésitez sur les métriques à privilégier, commencez par ces trois éléments :
|
Métrique |
Signification |
Seuil typique |
|
Temps de réponse (RT) |
Durée d'attente des utilisateurs pour une réponse |
Varie selon le secteur ; généralement < 500 ms pour les services Internet |
|
Débit (TPS/QPS) |
Nombre de transactions ou de requêtes traitées par seconde par le système |
Plus la valeur est élevée, mieux c'est ; dépend du volume d'activité |
|
Taux d'erreur |
Pourcentage de requêtes en échec |
< 0,6 % (taux de réussite >= 99,4 %) |
Ces trois métriques — latence, débit et disponibilité — correspondent à la méthode RED (Rate, Errors, Duration), largement utilisée dans les pratiques SRE et d'observabilité. Une fois que vous avez établi une base de référence pour ces indicateurs, élargissez l'analyse aux métriques au niveau des ressources et des composants décrites dans les sections suivantes.
Métriques de performance du système
Temps de réponse
Le temps de réponse (RT) correspond au délai écoulé entre l'envoi d'une requête par un client et la réception d'une réponse complète. Lors d'un test de performance, le RT est mesuré à partir du moment où la charge est appliquée jusqu'à ce que le serveur renvoie un résultat. Le RT s'exprime généralement en secondes ou en millisecondes.
Temps de réponse moyen vs percentile
Le temps de réponse moyen représente la moyenne des RT pour toutes les requêtes associées à la même transaction lorsque le système fonctionne en régime stable. Bien qu'utiles comme indicateur général, les moyennes peuvent masquer les valeurs aberrantes. Un système affichant un RT moyen de 200 ms peut présenter un p99 de 3 secondes, ce qui signifie que 1 % des utilisateurs subissent une latence inacceptable. Lorsque cela est possible, utilisez les métriques percentiles (p50, p90, p95, p99) conjointement avec la moyenne pour obtenir une image plus précise.
Catégories de temps de réponse :
|
Catégorie |
Description |
|
RT de transaction simple |
Opérations en une seule étape, telles qu'une requête ou une recherche |
|
RT de transaction complexe |
Opérations en plusieurs étapes impliquant des jointures, des calculs ou des appels externes |
|
RT de transaction spéciale |
Transactions dont les caractéristiques de performance connues diffèrent de la norme (documentez les spécificités lors de leur définition) |
Références sectorielles pour les transactions en ligne
|
Secteur |
RT acceptable |
|
Services Internet |
< 500 ms (par exemple, Taobao vise 10 ms) |
|
Services financiers |
< 1 s (< 3 s pour les transactions complexes) |
|
Assurance |
< 3 s |
|
Fabrication |
< 5 s |
Pour le traitement par lots, la durée acceptable dépend du volume de données et de la fenêtre temporelle disponible. À titre indicatif, les tâches par lots à grande échelle (telles que celles exécutées lors d'événements promotionnels comme le Double 11 ou la Promotion 99) doivent se terminer dans un délai de 2 heures.
Débit
Le débit mesure le nombre d'opérations traitées par unité de temps. Il existe trois métriques de débit courantes :
|
Métrique |
Nom complet |
Mesure |
|
TPS |
Transactions Per Second |
Transactions métier de bout en bout terminées par seconde |
|
QPS |
Queries Per Second |
Requêtes de base de données ou API traitées par seconde |
|
HPS |
Hits Per Second |
Requêtes HTTP (clics) reçues par le serveur par seconde |
Pour une application simple où chaque action utilisateur génère une seule requête, le TPS, le QPS et le HPS sont équivalents. Dans des systèmes plus complexes, le TPS reflète le flux de travail métier complet, le QPS compte les opérations de requête individuelles et le HPS comptabilise les accès HTTP bruts.
Des valeurs plus élevées indiquent une capacité de traitement plus importante. Les plages suivantes sont typiques :
|
Secteur |
Plage TPS typique |
|
Commerce électronique |
10 000 – 1 000 000 |
|
Services financiers (hors Internet) |
1 000 – 50 000 |
|
Assurance (hors Internet) |
100 – 100 000 |
|
Services Internet de taille moyenne |
1 000 – 50 000 |
|
Petits services Internet |
500 – 10 000 |
|
Fabrication |
10 – 5 000 |
Utilisateurs simultanés
Le nombre d'utilisateurs simultanés correspond au nombre d'utilisateurs activement connectés et effectuant des opérations à un instant donné. Dans les configurations de test, cette métrique est représentée par des utilisateurs virtuels (VU).
La relation entre les utilisateurs simultanés et la capacité du système dépend du modèle de connexion :
Connexions persistantes : Le nombre maximal d'utilisateurs simultanés représente directement la capacité de concurrence du système.
Connexions éphémères : Le nombre maximal d'utilisateurs simultanés n'est pas égal à la capacité de concurrence, car celle-ci dépend également de l'architecture du système et du débit. Si le système offre un débit élevé et que les connexions sont réutilisées efficacement, le nombre d'utilisateurs simultanés peut dépasser le nombre de connexions simultanées.
Choisir le mode de test approprié
Pour la plupart des systèmes utilisant des connexions éphémères, les tests basés sur le débit (mode TPS ou RPS) sont plus représentatifs que les tests basés sur la concurrence. Performance Testing (PTS) prend en charge le mode RPS, ce qui simplifie la configuration et la mesure des tests de débit.
Remarque : Les tests de performance visent généralement à mesurer la capacité de traitement du système plutôt que le nombre maximal d'utilisateurs simultanés. Un petit nombre d'utilisateurs simultanés générant des taux de requêtes élevés peut solliciter le système tout aussi efficacement qu'un grand nombre d'utilisateurs inactifs.
Taux d'erreur
Le taux d'erreur, également appelé ratio d'échec (FR), correspond au pourcentage de transactions échouées par rapport au total des transactions :
Error rate = (Failed transactions / Total transactions) x 100%Dans un système stable, les échecs de requête sont causés par des délais d'expiration, de sorte que le taux d'erreur est égal au taux de délai d'expiration.
Seuil : Le taux d'erreur doit rester inférieur à 0,6 % (6 pour mille), ce qui correspond à un taux de réussite de 99,4 % ou plus.
Métriques des ressources
Les métriques des ressources identifient les goulots d'étranglement de l'infrastructure. Surveillez-les côté serveur pendant les tests de charge.
CPU
|
Métrique |
Seuil |
Description |
|
Utilisation du CPU (globale) |
<= 75 % |
Utilisation totale du CPU dans les modes utilisateur, système, attente et inactif |
|
CPU sys% |
<= 30 % |
Temps passé en mode noyau |
|
CPU wait% |
<= 5 % |
Temps passé à attendre les E/S |
|
Charge CPU |
< nombre de cœurs CPU |
Longueur moyenne de la file d'attente des requêtes |
Ces seuils s'appliquent à chaque CPU, y compris aux instances monocœur. Le seuil de charge exige spécifiquement que la charge moyenne du système reste inférieure au nombre total de cœurs CPU.
Mémoire
Une utilisation élevée de la mémoire seule n'indique pas nécessairement un goulot d'étranglement. Les systèmes d'exploitation modernes utilisent la mémoire libre pour la mise en cache, de sorte qu'une utilisation de la mémoire à 100 % ne signifie pas forcément qu'il existe un goulot d'étranglement mémoire. Surveillez plutôt l'utilisation du swap comme principal indicateur de la pression sur la mémoire.
Seuil : L'utilisation du swap doit rester inférieure à 70 %. Le dépassement de cette valeur dégrade généralement les performances du système.
Débit disque
Le débit disque correspond au volume de données lu depuis ou écrit sur le disque par unité de temps sans défaillance du disque.
|
Métrique |
Description |
|
IOPS |
Opérations d'entrée/sortie par seconde |
|
Disk busy% |
Pourcentage de temps pendant lequel le disque traite activement des requêtes |
|
Longueur de la file d'attente du disque |
Nombre de requêtes d'E/S en attente |
|
Temps de service moyen |
Temps moyen nécessaire pour terminer une seule opération d'E/S |
|
Temps d'attente moyen |
Temps moyen pendant lequel une requête d'E/S attend dans la file d'attente |
|
Utilisation du disque |
Pourcentage de la capacité du disque consommée |
Seuil : Disk busy% doit rester inférieur à 70 %.
Débit réseau
Le débit réseau correspond au volume de données transmises sur le réseau par unité de temps sans défaillance réseau, mesuré en octets par seconde (B/s) ou en mégabits par seconde (Mbps).
Seuil : L'utilisation du réseau ne doit pas dépasser 70 % de la capacité maximale du lien ou du dispositif.
Paramètres du noyau
Les paramètres du noyau du système d'exploitation suivants affectent la capacité du système sous charge. Examinez et ajustez-les avant d'exécuter des tests de performance.
|
Paramètre |
Unité |
Description |
|
Maxuprc |
-- |
Nombre maximal de processus par utilisateur |
|
Max_thread_proc |
-- |
Nombre maximal de threads par processus |
|
Filecache_max |
Octets |
Mémoire physique maximale pour le cache d'E/S de fichiers |
|
Ninode |
-- |
Inodes maximaux en mémoire (HFS) |
|
Nkthread |
-- |
Nombre maximal de threads noyau simultanés |
|
Nproc |
-- |
Nombre maximal de processus simultanés |
|
Nstrpty |
-- |
Nombre maximal d'esclaves de pseudo-terminaux basés sur des flux |
|
Maxdsiz |
Octets |
Taille maximale du segment de données par processus |
|
maxdsiz_64bit |
Octets |
Taille maximale du segment de données par processus (64 bits) |
|
maxfiles_lim |
-- |
Nombre maximal de descripteurs de fichiers par processus |
|
maxssiz_64bit |
Octets |
Taille maximale de la pile par processus |
|
Maxtsiz |
Octets |
Taille maximale du segment de texte par processus |
|
nflocks |
-- |
Nombre maximal de verrous de fichiers |
|
maxtsiz_64bit |
Octets |
Taille maximale du segment de texte par processus (64 bits) |
|
msgmni |
-- |
Nombre maximal d'ID de files d'attente de messages IPC System V |
|
msgtql |
-- |
Nombre maximal de messages IPC System V |
|
npty |
-- |
Nombre maximal de pseudo-TTY BSD |
|
nstrtel |
-- |
Fichiers de périphérique telnet pris en charge par le noyau |
|
nswapdev |
-- |
Nombre maximal de périphériques de swap |
|
nswapfs |
-- |
Nombre maximal de systèmes de fichiers de swap |
|
semmni |
-- |
ID de sémaphores IPC System V |
|
semmns |
-- |
Sémaphores IPC System V |
|
shmmax |
Octets |
Taille maximale d'un segment de mémoire partagée System V |
|
shmmni |
-- |
ID de mémoire partagée System V |
|
shmseg |
-- |
Nombre maximal de segments de mémoire partagée System V par processus |
Métriques du middleware
Les métriques courantes pour les middleware basés sur Java (tels que Tomcat et WebLogic) se répartissent en trois catégories : garbage collection (GC), pool de threads et connexions JDBC.
|
Catégorie |
Métrique |
Unité |
Description |
|
GC |
Fréquence GC |
-- |
Événements de garbage collection partielle par intervalle de temps |
|
GC |
Fréquence Full GC |
-- |
Événements de garbage collection complète par intervalle de temps |
|
GC |
Durée moyenne du Full GC |
Secondes |
Temps moyen nécessaire pour terminer un cycle Full GC |
|
GC |
Durée maximale du Full GC |
Secondes |
Pause Full GC la plus longue observée |
|
GC |
Utilisation du tas |
% |
Pourcentage de mémoire du tas JVM utilisé |
|
Pool de threads |
Nombre de threads actifs |
-- |
Threads traitant actuellement des requêtes |
|
Pool de threads |
Requêtes utilisateur en attente |
-- |
Requêtes mises en file d'attente et en attente d'un thread |
|
JDBC |
Connexions JDBC actives |
-- |
Connexions à la base de données actuellement utilisées |
Références recommandées (sous des performances système normales) :
|
Métrique |
Consigne |
|
Threads actifs |
Min : 50, Max : 200 |
|
Connexions JDBC actives |
Min : 50, Max : 200 |
|
Fréquence Full GC |
Doit être peu fréquente ; une fréquence Full GC élevée indique une pression sur la mémoire |
|
Taille du tas JVM |
Définissez le minimum et le maximum à 1 024 Mo comme point de départ |
Métriques de la base de données
Les métriques courantes pour les bases de données relationnelles (telles que MySQL) couvrent l'exécution SQL, le débit, l'efficacité du cache et le verrouillage.
|
Catégorie |
Métrique |
Unité |
Description |
|
SQL |
Durée d'exécution |
Microsecondes |
Temps nécessaire pour exécuter une seule instruction SQL |
|
Débit |
QPS |
-- |
Requêtes traitées par seconde |
|
Débit |
TPS |
-- |
Transactions validées par seconde |
|
Taux de succès du cache |
Taux de succès du tampon de clés |
% |
Efficacité du cache du tampon d'index |
|
Taux de succès du cache |
Taux de succès du buffer InnoDB |
% |
Efficacité du cache du pool de buffers InnoDB |
|
Taux de succès du cache |
Taux de succès du cache de requêtes |
% |
Efficacité du cache des résultats de requêtes |
|
Taux de succès du cache |
Taux de succès du cache de table |
% |
Efficacité du cache des métadonnées de table |
|
Taux de succès du cache |
Taux de succès du cache de threads |
% |
Efficacité de la réutilisation des threads |
|
Verrou |
Attentes de verrou |
-- |
Nombre de fois qu'une requête a attendu un verrou |
|
Verrou |
Temps d'attente du verrou |
Microsecondes |
Temps total passé à attendre les verrous |
Seuils :
|
Métrique |
Consigne |
|
Durée d'exécution SQL |
Plus faible est préférable ; visez une exécution au niveau de la microseconde |
|
Taux de succès du cache |
>= 95 % |
|
Attentes de verrou et temps d'attente |
Plus faibles sont préférables ; des valeurs élevées indiquent une contention |
Métriques frontend
Les métriques frontend capturent l'expérience de l'utilisateur final dans les applications basées sur un navigateur.
Rendu de page
|
Métrique |
Unité |
Description |
|
First Contentful Paint (FCP) |
ms |
Temps écoulé jusqu'à l'apparition du premier contenu visible après la navigation vers une URL |
|
Temps de l'événement OnLoad |
ms |
Temps écoulé jusqu'à ce que le navigateur déclenche l'événement |
|
Temps de chargement complet |
ms |
Temps écoulé jusqu'à la fin de l'exécution de tous les scripts JavaScript |
Composition de la page
|
Métrique |
Unité |
Description |
|
Taille de la page |
Ko |
Taille totale de toutes les ressources téléchargées |
|
Nombre de requêtes |
-- |
Nombre total de requêtes réseau nécessaires pour charger la page (plus faible est préférable) |
Chronométrage réseau
|
Métrique |
Unité |
Description |
|
Temps de recherche DNS |
ms |
Temps nécessaire pour résoudre le nom de domaine |
|
Temps de connexion |
ms |
Temps nécessaire pour établir une connexion TCP/IP |
|
Temps serveur |
ms |
Temps passé par le serveur à traiter la requête |
|
Temps de transfert |
ms |
Temps nécessaire pour transmettre le corps de la réponse |
|
Temps d'attente |
ms |
Temps d'attente pour qu'une ressource devienne disponible |
Seuils : Réduisez la taille de la page (utilisez la compression) et visez les temps de rendu de page les plus courts possibles.
Métriques de stabilité
Les tests de stabilité déterminent si le système maintient des performances cohérentes sur de longues périodes sous une charge soutenue.
Conditions de test : Appliquez une charge correspondant à 80 % de la capacité maximale du système ou au pic quotidien attendu.
Exigences de durée :
|
Type de système |
Durée minimale d'exécution stable |
|
Système aux heures ouvrables (8 h/jour) |
8 heures |
|
Système 24/7 |
24 heures |
Critères de réussite :
Le TPS reste stable sans fluctuations significatives.
Aucune fuite de ressources (mémoire, connexions, handles de fichiers) ni exception ne se produit.
Si le système ne parvient pas à maintenir des performances stables, attendez-vous à une dégradation ou à des plantages à mesure que la durée de la charge augmente.
Métriques de traitement par lots
Le débit du traitement par lots correspond au volume de données traitées par unité de temps, généralement mesuré en enregistrements par seconde. L'efficacité du traitement est la métrique principale pour estimer les fenêtres de temps du traitement par lots.
Considérations :
Plusieurs travaux par lots peuvent s'exécuter simultanément avec des fenêtres temporelles qui se chevauchent. Tenez-en compte lors de la planification de la capacité.
Les travaux par lots de longue durée peuvent dégrader les performances des transactions en ligne. Planifiez les fenêtres de traitement par lots afin de minimiser le chevauchement avec le trafic de pointe.
Seuils :
Pour les grands volumes de données, maintenez la fenêtre de traitement par lots aussi courte que possible.
Le traitement par lots ne doit pas dégrader les temps de réponse des transactions en ligne.
Métriques d'évolutivité
L'évolutivité quantifie la relation entre les ressources ajoutées et le gain de performance résultant dans un déploiement en cluster ou distribué :
Scalability = (Performance increase / Original performance) / (Resource increase / Original resources) x 100%Exécutez plusieurs tests en ajoutant progressivement des ressources pour observer la tendance de l'évolutivité. Un système hautement évolutif présente une relation linéaire ou quasi linéaire entre les ressources et les performances. Les systèmes distribués à grande échelle ont souvent une évolutivité élevée.
Seuils :
Idéal : Mise à l'échelle linéaire (100 %).
Acceptable : Augmentation des performances d'au moins 70 % par rapport à l'augmentation des ressources.
Métriques de fiabilité
Les tests de fiabilité valident que le système récupère après des pannes sans perte de données ni temps d'arrêt prolongé.
Standby actif
Évaluez les points suivants lors du basculement et du retour arrière :
|
Point de contrôle |
Ce qu'il faut vérifier |
|
Réussite du basculement |
Le nœud de secours prend-il le relais et combien de temps dure le basculement ? |
|
Continuité des activités pendant le basculement |
Le service est-il interrompu pendant le basculement ? |
|
Réussite du retour arrière |
Le nœud principal reprend-il ses fonctions et combien de temps dure le retour ? |
|
Continuité des activités pendant le retour arrière |
Le service est-il interrompu pendant le retour ? |
|
Intégrité des données |
Quelle quantité de données, le cas échéant, est perdue lors du retour ? |
Exécutez ces tests sous une charge réaliste en utilisant un outil de génération de pression pour reproduire les conditions de production.
Architecture en cluster
|
Point de contrôle |
Ce qu'il faut vérifier |
|
Panne de nœud |
Le service est-il interrompu lorsqu'un nœud du cluster tombe en panne ? |
|
Ajout de nœud |
L'ajout d'un nouveau nœud nécessite-t-il un redémarrage du système ? |
|
Redémarrage après récupération du nœud |
Le système doit-il être redémarré lorsqu'un nœud récupéré est rajouté au cluster ? |
|
Continuité après récupération du nœud |
Le service est-il interrompu lorsqu'un nœud récupéré est rajouté au cluster ? |
|
Durée du basculement |
Combien de temps dure le basculement du nœud ? |
Exécutez les tests de fiabilité du cluster sous charge pour obtenir des résultats conformes au comportement en production.
Sauvegarde et restauration
|
Point de contrôle |
Ce qu'il faut vérifier |
|
Réussite de la sauvegarde |
La sauvegarde se termine-t-elle et combien de temps prend-elle ? |
|
Automatisation de la sauvegarde |
Le processus de sauvegarde est-il scripté et reproductible ? |
|
Réussite de la restauration |
La restauration se termine-t-elle et combien de temps prend-elle ? |
|
Automatisation de la restauration |
Le processus de restauration est-il scripté et reproductible ? |
Choisir les bonnes métriques pour votre test
Tous les tests ne nécessitent pas toutes les métriques. Sélectionnez les métriques en fonction de votre objectif de test :
|
Objectif du test |
Métriques recommandées |
|
Mesurer la capacité du système |
Temps de réponse, TPS/QPS, taux d'erreur, CPU, mémoire |
|
Valider les performances frontend |
FCP, temps OnLoad, taille de la page, nombre de requêtes, chronométrage réseau |
|
Vérifier la stabilité sous charge soutenue |
Tendance du TPS dans le temps, utilisation des ressources (vérifiez les fuites) |
|
Évaluer le traitement par lots |
Débit de traitement (enregistrements/s), durée de la fenêtre de traitement par lots |
|
Confirmer l'évolutivité |
Ratio d'évolutivité lors des ajouts incrémentiels de ressources |
|
Tester la fiabilité et le basculement |
Temps de basculement/retour, perte de données, continuité du service |
|
Évaluer la capacité d'utilisateurs simultanés |
Utilisateurs virtuels, limites de connexion, temps de réponse sous concurrence |
Après avoir collecté les métriques, documentez les prérequis du test, y compris les profils de charge de travail, les volumes de données et les spécifications des ressources système, afin de rendre les résultats reproductibles et comparables. Lors de la vérification de la capacité de performance du système, spécifiez les exigences relatives aux métriques dans votre plan de test en vous basant sur les définitions des métriques décrites dans ce guide.