Technique de rythme (Partie 1)

Le but de cette entrée est d’expliquer une méthode pour décrire la vitesse à laquelle les utilisateurs arrivent dans un application Web. Remarque : Dans l’anglais, le terme “pacing” désigne ce que nous utiliserons dans cet article.

Qu’est-ce que le Pacing ? #

Le Pacing se réfère à l’intervalle entre les visites d’une application Internet. Le Pacing représente le nombre de scénarios de tests qui se produisent dans une certaine période de temps. Remarque : Consultez mon collègue Antonio pour une excellente explication des scénarios de test.

De même, le Pacing représente une exigence en ce sens que le Pacing définit l’objectif (par exemple, en termes d’horaire de visites) que l’apprentissage est attendu d’un application. De manière plus générale, il s’agit d’une criterium acceptation des résultats du test de charge (un autre critère acceptation pourrait être les temps de réponse par exemple).

Incluant la Cadence dans une Épreuve Permet de Maintenir un Rythme Constant de Départ à l’Application et Donne ainsi Exactement L’Accès au Charge Souhaité. En Conséquence, Cela Permet de Déterminer la Capacité du Charge que l’Application peut Accepter ou Soutenir.

Enfin, il est important de mentionner que cette technique s’applique aux applications du type modèles ouverts où les visites à l’application arrivent indépendamment (asynchronement). De manière plus discrétionnaire, c’est la caractéristique qui prédomine dans la grande majorité des tâches qui se produisent sur Internet (par exemple, e-commerce).

La technique utilisant les groupes de fils d’arrivée

Il existe plusieurs techniques pour implémenter le Pacing dans JMeter, mais cet article se concentre sur une basée sur la Thread Group Arrivals. Ce qui rend cette TG importante est qu’elle maintient le chargement (la charge) en créant des threads/vus nécessaires.

Nous montrons comment cela fonctionne en utilisant un exemple simple. Dans cet exemple, le client exige que l’application supporte 240 vues/min.

Comme indiqué par cette table, le session est composée de quatre étapes (implémentées à l’aide d’un Sampler Dummy). Chaque étape est attribuée une Temps de Réponse, et pour les trois dernières étapes, un ThinkTime constant de 2 secondes respectivement. De plus, nous utilisons 3 écouteurs pour aider à analyser les résultats.

Le diagramme illustre la configuration de la Groupe d’Arrivées Threads. En raison du taux requis est de 240 visites par minute, nous avons entré cette quantité dans l’espace indiqué sous le titre Taux cible (visites/min). De plus, nous avons entré le temps de test à 30 minutes dans l’espace indiqué sous le titre Temps d’attente du taux cible (min).

Important Note: Pacing s’applique à la totalité du séance, et comme conséquence à chaque étape (demandes) de la scénario.

Résultat et Analyse #

Après la fin du test, le témoin de rapport Aggreate affiche les résultats suivants :

Premièrement, nous observons que le nombre d’exécutions pour chaque étape (séries) est environ 7,200. Divisant ce nombre par 30 (durée en minutes), le résultat est 240 exécutions par minute. C’est la requête pour le test!

Comme nous l’avons mentionné à la fois, le TG Arrivées génère les Threads/VUsers nécessaires pour maintenir le chargement. Pour déterminer cette quantité, nous pouvons utiliser le plugin Threads Actives au fil du temps de cette manière :

Selon la courbe, le nombre d’UVisseurs est environ de 64. De plus, les UVisseurs (utilisateurs actifs) sont calculés selon l’une des lois de la Théorie des Files, la Loi de Little.

# active users = active users + paused users (ThinkTime)

# active users = (Throughput average * Response time average) + (Throughput average * Think time average)`

# active users = 15.9 * 2.5 + 15.9 * 1.5 = 63.60

Concluison #

Toutefois, le Groupe des Filaments d’Arrivées est intuitif et relativement facile à configurer, mais il présente quelques limitations : les utilisateurs arrivent à une vitesse constante, ce qui n’est pas réaliste en raison de la nature totalement aléatoire/random des arrivées sur le web. De plus, évaluer le nombre d’utilisateurs actifs (vusers) n’est pas un processus direct.