Dans cet article, nous allons discuter des éléments essentiels concernant le débit dans les tests de performances.
Avant de commencer avec les détails, examinons quelques éléments essentiels des tests de performance.
Les tests de performance sont importants car :
Vous pouvez commencer les tests de performances le plus tôt possible dans les étapes de développement de votre application logicielle. De cette façon, vous pouvez optimiser votre serveur Web et éviter des coûts commerciaux ultérieurs.
Découvrir les problèmes de performances après le déploiement de l'application signifie de nombreuses heures de travail pour résoudre les problèmes. Cela peut donc coûter très cher.
Dès que les pages Web de base de l'application fonctionnent, l'équipe d'assurance qualité doit effectuer les tests de charge initiaux. À partir de ce moment, ils doivent effectuer régulièrement des tests de performances pour chaque version.
Il existe différents outils et critères pour tester les performances des applications. Ici, nous allons parler d'une mesure importante, à savoir le débit.
Chaque application logicielle ou site Web compte de nombreux utilisateurs qui effectuent différentes demandes. Les testeurs doivent s'assurer que l'application répond à la capacité requise de demandes avant de la mettre en ligne.
Certaines bases des tests de performance doivent être mesurées au cours du processus. Le débit en est un . Voyons quel est le débit dans les tests de performances.
Avant de commencer le test, nous devons définir un objectif de débit de performance réaliste, afin d'obtenir des résultats plus précis et fiables.
Voici quelques facteurs importants pour déterminer un débit réaliste :
Ici, nous expliquerons le concept de débit à l'aide d'un exemple concret. Imaginez qu'il y ait un stand de restauration rapide nommé "Yummy Burgers". Ils servent des hamburgers et des frites pour les clients.
Disons que "Yummy Burgers" a trois travailleurs dans le stand, et chaque travailleur prend toujours 5 minutes pour servir la nourriture à un client.
Ainsi, s'ils ont trois clients alignés pour être servis par trois employés, cela signifie que "Yummy Burgers" peut servir de la nourriture à trois clients en 5 minutes.
Par conséquent, si nous devions faire un rapport de performance de "Yummy Burgers", cela montrerait que son débit est de trois clients toutes les cinq minutes.
C'est le dilemme de Yummy Burgers que, quel que soit le nombre de clients qui attendent la nourriture, le nombre maximum qu'ils peuvent gérer pendant une période de temps spécifique sera toujours le même, c'est-à-dire trois. C'est le débit maximal .
Au fur et à mesure que de plus en plus de clients font la queue pour la nourriture, ils doivent attendre leur tour, créant ainsi une file d'attente.
Le même concept s'applique au test d'une application Web.
Si une application Web reçoit 100 requêtes par seconde, mais qu'elle ne peut gérer que 70 requêtes par seconde, les 30 requêtes restantes doivent attendre dans une file d'attente.
Dans les tests de performances, nous désignons le débit par « Transactions par seconde » ou TPS .
L'utilisation d'Apache JMete r est très populaire pour tester les performances d'une application logicielle. JMeter est utile pour déterminer le nombre maximum d'utilisateurs simultanés que l'application peut gérer et fournit également une analyse graphique pour les tests de performances.
JMeter fournit de nombreuses façons d'enregistrer la valeur du débit. Voici quelques écouteurs JMeter que vous pouvez utiliser à cette fin :
JMeter fournit également un composant de minuterie, ' Constant Throughput Timer' , que vous pouvez utiliser pour définir la valeur de Transactions per Second (TPS) afin de tester la charge de l'application.
Maintenant, nous allons montrer l'utilisation du débit dans le test de performance à l'aide de JMeter. Supposons que nous allons effectuer un exemple de test avec 100 threads simultanés et suivre la valeur du débit.
Supposons que la dernière version de JMeter soit installée sur notre système et que nous ayons déjà effectué toutes les autres configurations requises. Maintenant, nous devons construire un plan de test.
Dans ce test, nous allons définir cinq éléments ThreadGroup. Chacun de ces éléments aura un temps de montée en puissance différent, c'est-à-dire 0, 15, 25, 35 et 45. Le temps de montée en puissance est la durée de démarrage de chaque thread. Nous allons configurer 100 utilisateurs dans ces éléments ThreadGroup.
Si nous voulons configurer un plus grand nombre d'utilisateurs, plus de temps de montée en puissance sera nécessaire.
Ces groupes de threads auront un échantillonneur HTTP qui générera des requêtes sur la page d'accueil d'un exemple de site Web (supposons www.samplesite.com).
Dans le cas d'utilisation 1, nous avons un élément ThreadGroup configuré avec 100 threads et son temps de montée en puissance est de 0.
Le champ "Nombre de threads" sera défini sur 100. Cela signifie que 100 utilisateurs enverront des demandes à la fois. De même, nous pouvons également configurer les 4 threads restants et définir leur temps de montée en puissance sur 15, 25, 35 et 45. En outre, nommez les échantillonneurs pour chaque groupe de threads.
Comme mentionné précédemment, ces échantillonneurs HTTP pointeront vers la page d'accueil de l'exemple de site Web.
Il est nécessaire d'exécuter ces groupes de threads dans un ordre approprié. À cette fin, sélectionnez "Plan de test" dans le panneau de configuration et cochez le champ "Exécuter les groupes de threads consécutivement".
« Aggregate Report » est un écouteur qui est utilisé pour analyser et observer les résultats des tests. Pour utiliser cet écouteur, faites un clic droit sur "Plan de test" et sélectionnez :
Ajouter → Écouteur → Rapport agrégé
Cliquez ensuite sur l'icône de démarrage pour exécuter le test.
Voyons maintenant comment comprendre les résultats du débit du rapport agrégé.
Le premier groupe de threads avec un temps de montée de 0 montre que tous les threads mettent une charge instantanée sur le serveur en démarrant immédiatement. Ce scénario a un débit assez élevé, mais il n'est pas pratique. Donc, cela ne montrera pas une sortie réaliste.
Les deuxième et troisième groupes de threads ont un temps de montée en puissance d'une plage réaliste, ils sont donc plus susceptibles d'afficher un débit de performances et un temps de chargement de demande appropriés.
Les groupes de threads quatre et cinq ont un temps de montée en puissance plus élevé, ce qui signifie que leur débit diminuera.
Par conséquent, la sortie fiable peut être déterminée à partir des résultats des deuxième et troisième groupes de threads.
La décision de déployer une nouvelle version ou une modification repose sur la capacité de l'application à gérer des TPS spécifiques. Ainsi, le plan de test de performance a certains objectifs de débit. Mais nous devons nous assurer que ces objectifs sont réalistes et représentent les véritables caractéristiques de la production.
Le plan de test est en vain si nous le réussissons en utilisant des conditions irréalistes. Par exemple, le plan de test que nous avons décrit ci-dessus avait des valeurs de débit plus élevées pour le premier groupe de threads, mais il ne décrivait pas le scénario réel de l'environnement en direct.
Ainsi, en utilisant de telles méthodes, nous ne pouvons pas avoir la bonne idée si notre application va gérer la charge réelle ou non. Par conséquent, la mise en place de tests adaptés est cruciale.
En un mot, le débit est un indicateur de performance crucial des applications Web . Mais, dépendre uniquement des métriques de débit ne suffit pas. Par conséquent, il doit être vérifié avec la latence et les temps de réponse .
Il est également très important de créer un débit réaliste pour atteindre les objectifs de test de performance définis.