Les tests de performances peuvent parfois être interprétés à tort comme martelant le serveur avec un débit élevé de requêtes, mais des concepts tels que le temps de réflexion, le rythme et les retards nous aident à obtenir les modèles d’utilisateurs réels qui se produisent au cours de la production. Concevoir le scénario de test de performance comme proche de modèles utilisateur réalistes est très crucial pour obtenir des résultats qui détectent de véritables problèmes et goulots d’étranglement dans les applications. Dans le même contexte, pensez que le temps et le rythme ont une importance significative tout en élaborant des scénarios de test de charge. Dans cet article, nous aborderons le temps de réflexion, le rythme et les retards, ainsi que leur signification, les meilleures pratiques et la façon dont nous pouvons configurer ces métriques dans le cadre de notre scénario de test de charge avec LoadView. Comprenons d’abord ce que le temps de réflexion et le rythme dans les tests de charge signifient lorsqu’il s’agit de tests de charge.
Qu’est-ce que Think Time?
Pensez que le temps dans le test de charge est le décalage horaire entre chaque action d’un seul utilisateur. Un utilisateur tout en naviguant sur l’application passe un certain temps (pensez temps) avant de faire quelques actions sur le site. Par exemple, sur une application Web de commerce électronique, un utilisateur clique sur une vignette de produit, accède à sa page d’affichage de produit, puis attend d’y consommer et de lire le contenu de cette page avant de cliquer sur le bouton Ajouter au panier . Le temps passé de cliquer sur la vignette du produit à cliquer sur Ajouter à Panier est appelé temps de réflexion. La valeur du temps de réflexion varie d’un utilisateur à l’autre, mais pour notre scénario de test, nous pouvons prendre la moyenne du temps de réflexion.
En règle générale, lorsque vous pensez aux tests de charge et de stress, vous pensez simplement à servir de grandes quantités d’utilisateurs simultanés par rapport à vos applications Web, sites Web ou API pour voir comment ils fonctionnent sous stress. Bien que les tests de résistance aient leur place dans les tests de performance, ce type de test de performance n’est pas adapté pour comprendre les performances du point de vue de l’utilisateur, car cela ne simule pas vraiment des scénarios réels. C’est là que le temps de réflexion entre en jeu pour aider à mieux simuler les étapes du parcours utilisateur, telles que les chemins d’achat, la recherche d’un produit ou la connexion à un compte, par exemple. Chacune de ces étapes a des valeurs de temps de réflexion différentes et il est important de les prendre en considération lors des tests de charge.
Qu’est-ce que Pacing?
Le rythme est utilisé pendant les tests de charge pour s’assurer que nous sommes en cours d’exécution du test avec la transaction désirée par seconde. C’est le décalage horaire entre chaque itération complète du flux d’affaires. Il nous aide à contrôler le nombre de demandes envoyées au serveur par seconde. Le rythme est légèrement différent du temps de réflexion. Comme nous l’avons décrit plus haut, pensez que le temps est le délai entre les actions dans les itérations ou les étapes. Comme nous l’avons mentionné, le test de charge n’est pas de frapper le serveur avec autant de demandes que possible sans délai, le plan de test avec le débit désiré peut être atteint en trouvant la valeur correcte de rythme. En outre, le rythme, avec le temps de réflexion, aide également à mieux simuler l’expérience de l’utilisateur et fournit un test de charge plus réaliste. Il y a généralement une courte période de temps entre les itérations, il est donc important de prendre en considération lors de la mise en place de vos tests de charge.
Pourquoi il est important d’introduire des retards dans les scénarios de test de charge
Le test de charge de l’application avant le déploiement complet de l’étape nous évite une mauvaise expérience potentielle rencontrée par les utilisateurs finaux avec des problèmes, comme des délais d’attente, des réponses lentes de page et des temps d’arrêt. Afin de nous rapprocher des résultats réalistes des tests de charge et de trouver des problèmes, le cas échéant, nous devrions amener notre scénario de test à être aussi réaliste que possible. L’examen du temps de réflexion et du rythme dans la conception de nos scénarios de test nous aide à tester comment la gestion de file d’eau, l’utilisation du thread et la gestion de la mémoire du serveur se comportent sous une lourde charge. Par exemple, si nous essayons d’ajouter du temps de réflexion entre chaque action simultanée de l’utilisateur, pendant ce délai, le serveur a tendance à choisir d’autres tâches en attente de la file d’attente, exécute la tâche suivante, puis choisit l’ancienne tâche à nouveau. Cette étape est exactement ce qui se passe sur la production avec les utilisateurs réels. L’ajout de temps de réflexion augmente également le temps passé par l’utilisateur sur l’application, qui identifie les problèmes liés à la capacité de manipulation simultanée de l’utilisateur du serveur.
Comment calculer les retards pour les demandes
Le nombre d’utilisateurs virtuels simultanés, les retards et la transaction par seconde (TPS) varient pour chaque application. Donc, pour calculer quels devraient être les retards pour notre application, nous pouvons utiliser ci-dessous les formules.
Durée du test de charge (en secondes) * (TPS + Retards) * Nombre d’utilisateurs simultanés = Total des transactions
Supposons que par exemple, nous aimerions générer 100 000 transactions, chaque transaction a un temps de réponse de 5 secondes et nous exécuterions le test pendant 10 minutes (600 secondes). Calculons le nombre d’utilisateurs simultanés requis en supposant que si nous avons 3 secondes de temps de réflexion dans les retards. En utilisant la formule ci-dessus, nous pouvons calculer le nombre d’utilisateurs simultanés requis. Dans notre cas, ce serait 100.000/(8*10*60) qui sort pour être d’environ 21 utilisateurs. De cette façon, nous pouvons trouver les retards et les numéros requis pour les tests de charge.
Meilleures pratiques avant d’exécuter un test de charge
Pour obtenir les meilleurs résultats et les plus précis des tests de performance, nous devrions envisager de répondre à la question ci-dessous qui se concentrent sur les meilleures pratiques pendant le test de charge.
Nombre d’utilisateurs simultanés
Nous aurions besoin de comprendre à ce que les utilisateurs simultanés attendus que nous voulons comparer notre application.
Simulation de scénarios réels de test utilisateur
Concevoir le scénario de test en gardant à l’esprit le voyage réel de l’utilisateur, penser aux temps passés par l’utilisateur et les retards entre chaque test.
Charges virtuelles géolocal distribuées
Les injecteurs de charge générant des charges doivent être séparés en fonction de géolocalisations spécifiques, si notre application devrait recevoir du trafic de partout dans le monde.
Mise en place de la période de montée en puissance
La définition de la période de montée en puissance contribue également à augmenter progressivement l’échelle de l’application et rend notre scénario de test réaliste pour le comportement de l’application.
Durée du test
La durée d’un test est importante pour comprendre comment le serveur se comporte lorsqu’il est soumis à une charge continue en ligne droite.
Ajout de retards avec LoadView
LoadView inclut l’enregistreur Web EveryStep, qui offre la facilité de créer des scénarios de test en enregistrant les actions effectuées par nous dans un navigateur. Il imite les étapes exactes et le comportement effectué par l’utilisateur, recueille tous les points de données, comme les sélecteurs, les actions et les retards. Tout en créant notre scénario de test, nous serions tenus d’imiter le voyage utilisateur réel avec des retards de temps de réflexion. Une fois que nous avons arrêté l’enregistrement, il crée un script qui peut être rediffusé avec les utilisateurs simultanés désirés. Comme vous pouvez le voir sur l’image ci-dessous, nous pouvons également modifier le script et mettre à jour les retards pour les étapes individuelles, au besoin pour le test. En savoir plus sur l’édition des scripts EveryStep Web Recorder.
Le script développé avec une réelle interaction utilisateur avec l’application et le voyage de l’utilisateur est considéré comme la meilleure approche qui peut nous aider à obtenir des résultats précis hors test de charge.
Profil de comportement de l’utilisateur
En outre, vous avez la possibilité de modifier le comportement des utilisateurs à partir de la plate-forme LoadView. Comme vous pouvez le voir dans l’image ci-dessous, vous pouvez choisir parmi Normal Delay ou choisir Custom Delay pour définir le comportement spécifique de l’utilisateur et les retards pour vos applications. En savoir plus sur l’ajustement du comportement de l’utilisateur.
Pensées de séparer : Test de charge : temps de réflexion, rythme et retards
Tester les performances d’une application est un aspect essentiel avant de l’envoyer en production. Il ne peut nous aider à trouver ces problèmes précis liés aux performances que si les meilleures pratiques sont suivies et que des scénarios de test sont développés qui couvrent les trajets réels des utilisateurs sur l’application. Dans cet article, nous avons examiné comment garder à l’esprit le temps de réflexion et les retards de rythme lors de la création de la conception de scénarios de test peut aider à trouver les problèmes sous-dessous du système. Il nous aide à trouver des problèmes tels que les délais d’expiration des pages, la lenteur de la réponse de la page, le temps de réponse et les erreurs de serveur bien à l’avance à charge élevée.
Ces stratégies peuvent nous aider à nous orienter vers des applications et des sites Web réactifs et fiables. Essayez l’enregistreur Web EveryStep dès maintenant et voyez à quelle vitesse vous pouvez créer des scripts pour vos applications.
Inscrivez-vous à LoadView dès aujourd’hui et recevez des tests de charge gratuits. Des questions sur la plate-forme LoadView ? Tendre la main à notre équipe de soutien pour parler à l’un de nos ingénieurs de performance.