Conseils JMeter

JMeter est un outil open source populaire pour les tests de charge, avec de nombreuses fonctionnalités de modélisation utiles telles que les éléments de groupe de threads, de minuterie et d'échantillonneur HTTP. Cet article complète le manuel de l'utilisateur de JMeter et fournit des instructions sur l'utilisation de certains des éléments de modélisation JMeter pour développer un script de test de qualité.

Cet article aborde également une question importante dans un contexte plus large: la spécification des exigences de temps de réponse précises et la validation des résultats des tests. Plus précisément, une méthode statistique rigoureuse, l'analyse des intervalles de confiance, est appliquée.

Veuillez noter que je suppose que les lecteurs connaissent les bases de JMeter. Les exemples de cet article sont basés sur JMeter 2.0.3.

Déterminer la période de montée en puissance d'un groupe de threads

Le premier ingrédient de votre script JMeter est un groupe de threads, examinons-le d'abord. Comme le montre la figure 1, un élément Thread Group contient les paramètres suivants:

  • Le nombre de fils.
  • La période de montée en puissance.
  • Le nombre d'exécutions du test.
  • Au démarrage, si le test s'exécute immédiatement ou attend une heure programmée. Dans ce dernier cas, l'élément Thread Group doit également inclure les heures de début et de fin.

Chaque thread exécute le plan de test indépendamment des autres threads. Par conséquent, un groupe de threads est utilisé pour modéliser les utilisateurs simultanés. Si la machine cliente exécutant JMeter manque de puissance de calcul suffisante pour modéliser une charge lourde, la fonction de test distributif de JMeter vous permet de contrôler plusieurs moteurs JMeter distants à partir d'une seule console JMeter.

La période de démarrage indique à JMeter la durée de création du nombre total de threads. La valeur par défaut est 0. Si la période de montée en puissance n'est pas spécifiée, c'est-à-dire que la période de démarrage est de zéro, JMeter créera immédiatement tous les threads. Si la période de démarrage est définie sur T secondes et que le nombre total de threads est N, JMeter créera un thread toutes les T / N secondes.

La plupart des paramètres d'un groupe de threads sont explicites, mais la période de montée en puissance est un peu étrange, car le nombre approprié n'est pas toujours évident. D'une part, la période de montée en puissance ne doit pas être nulle si vous avez un grand nombre de threads. Au début d'un test de charge, si la période de montée en puissance est nulle, JMeter créera tous les threads à la fois et enverra des requêtes immédiatement, saturant ainsi potentiellement le serveur et, plus important encore, augmentant de manière trompeuse la charge. Autrement dit, le serveur peut devenir surchargé, non pas parce que le taux de succès moyen est élevé, mais parce que vous envoyez simultanément toutes les premières requêtes des threads, ce qui entraîne un taux de succès initial inhabituel. Vous pouvez voir cet effet avec un écouteur JMeter Aggregate Report.

Comme cette anomalie n'est pas souhaitable, par conséquent, la règle de base pour déterminer une période de montée en puissance raisonnable est de maintenir le taux de réussite initial proche du taux de réussite moyen. Bien sûr, vous devrez peut-être exécuter le plan de test une fois avant de découvrir un nombre raisonnable.

De même, une période de montée en puissance importante n'est pas non plus appropriée, car la charge de pointe peut être sous-estimée. Autrement dit, certains threads n'ont peut-être même pas démarré, tandis que certains threads initiaux se sont déjà terminés.

Alors, comment vérifier que la période de montée en puissance n'est ni trop petite ni trop grande? Tout d'abord, devinez le taux de réussite moyen, puis calculez la période de montée en puissance initiale en divisant le nombre de threads par le taux de réussite estimé. Par exemple, si le nombre de threads est de 100 et que le taux de succès estimé est de 10 hits par seconde, la période de montée en puissance idéale estimée est de 100/10 = 10 secondes. Comment obtenez-vous un taux de réussite estimé? Il n'y a pas de moyen facile. Il vous suffit d'exécuter le script de test une fois en premier.

Deuxièmement, ajoutez un écouteur de rapport agrégé, illustré à la figure 2, au plan de test; il contient le taux de réussite moyen de chaque requête individuelle (échantillonneurs JMeter). Le taux de réussite du premier échantillonneur (par exemple, une requête HTTP) est étroitement lié à la période de montée en puissance et au nombre de threads. Ajustez la période de montée en puissance de sorte que le taux de réussite du premier échantillonneur du plan de test soit proche du taux de réussite moyen de tous les autres échantillonneurs.

Troisièmement, vérifiez dans le journal JMeter (situé dans JMeter_Home_Directory / bin) que le premier thread qui se termine se termine bien après le démarrage du dernier thread. Le décalage horaire entre les deux doit être aussi éloigné que possible.

En résumé, la détermination d'un bon temps de montée est régie par les deux règles suivantes:

  • Le taux de réussite du premier échantillonneur doit être proche du taux de réussite moyen des autres échantillonneurs, évitant ainsi une petite période de montée en puissance.
  • Le premier fil qui se termine se termine bien après le démarrage du dernier fil, de préférence aussi loin que possible, évitant ainsi une période de montée en puissance importante

Parfois, les deux règles entrent en conflit. Autrement dit, vous ne pouvez tout simplement pas trouver une période de montée en puissance appropriée qui respecte les deux règles. Un plan de test trivial pose généralement ce problème, car, dans un tel plan, vous manquez de suffisamment d'échantillonneurs pour chaque thread; ainsi, le plan de test est trop court et un thread termine rapidement son travail.

L'utilisateur pense l'heure, la minuterie et le serveur proxy

Un élément important à prendre en compte dans un test de charge est le temps de réflexion, ou la pause entre les requêtes successives. Diverses circonstances entraînent le retard: l'utilisateur a besoin de temps pour lire le contenu, remplir un formulaire ou rechercher le bon lien. Ne pas prendre correctement en compte le temps de réflexion conduit souvent à des résultats de test très biaisés. Par exemple, l'évolutivité estimée, c'est-à-dire la charge maximale (utilisateurs simultanés) que le système peut supporter, apparaîtra faible.

JMeter fournit un ensemble d'éléments de minuterie pour modéliser le temps de réflexion, mais une question demeure: comment déterminer un temps de réflexion approprié? Heureusement, JMeter offre une bonne réponse: l'élément JMeter HTTP Proxy Server.

Le serveur proxy enregistre vos actions lorsque vous parcourez une application Web avec un navigateur normal (tel que FireFox ou Internet Explorer). De plus, JMeter crée un plan de test lors de l'enregistrement de vos actions. Cette fonctionnalité est extrêmement pratique à plusieurs fins:

  • Vous n'avez pas besoin de créer une requête HTTP manuellement, en particulier les paramètres de formulaire fastidieux. (Cependant, les paramètres non anglais peuvent ne pas fonctionner correctement.) JMeter enregistrera tout dans les demandes générées automatiquement, y compris les champs masqués.
  • Dans le plan de test généré, JMeter inclut tous les en-têtes HTTP générés par le navigateur pour vous, tels que User-Agent (par exemple, Mozilla / 4.0) ou AcceptLanguage (par exemple, zh-tw, en-us; q = 0.7, zh- cn; q = 0,3).
  • JMeter peut créer des minuteries de votre choix, où le temps de retard est réglé en fonction du retard réel pendant la période d'enregistrement.

Voyons comment configurer JMeter avec la fonction d'enregistrement. Dans la console JMeter, cliquez avec le bouton droit sur l'élément WorkBench et ajoutez l'élément HTTP Proxy Server. Notez que vous cliquez avec le bouton droit sur l'élément WorkBench, pas sur l'élément Plan de test, car la configuration ici est pour l'enregistrement, pas pour un plan de test exécutable. Le but de l'élément HTTP Proxy Server est de vous permettre de configurer le serveur proxy du navigateur afin que toutes les requêtes passent par JMeter.

Comme illustré dans la figure 3, plusieurs champs doivent être configurés pour l'élément HTTP Proxy Server:

  • Port: port d'écoute utilisé par le serveur proxy.
  • Contrôleur cible: contrôleur dans lequel le proxy stocke les échantillons générés. Par défaut, JMeter recherchera un contrôleur d'enregistrement dans le plan de test actuel et y stockera les échantillons. Vous pouvez également sélectionner n'importe quel élément de contrôleur répertorié dans le menu. Habituellement, la valeur par défaut est correcte.
  • Regroupement: comment vous souhaitez regrouper les éléments générés dans le plan de test. Plusieurs options sont disponibles, et la plus judicieuse est probablement "Stocker le 1er échantillonneur de chaque groupe uniquement", sinon, les URL incorporées dans une page comme celles des images et des JavaScripts seront également enregistrées. Cependant, vous souhaiterez peut-être essayer l'option par défaut «Ne pas regrouper les échantillons» pour découvrir ce que JMeter crée exactement pour vous dans le plan de test.
  • Modèles à inclure et modèles à exclure: vous aide à filtrer certaines demandes indésirables.

Lorsque vous cliquez sur le bouton Démarrer, le serveur proxy démarre et commence à enregistrer les requêtes HTTP qu'il reçoit. Bien entendu, avant de cliquer sur Démarrer, vous devez configurer les paramètres du serveur proxy de votre navigateur.

Vous pouvez ajouter un minuteur en tant qu'enfant de l'élément HTTP Proxy Server, ce qui demandera à JMeter d'ajouter automatiquement un minuteur en tant qu'enfant de la requête HTTP qu'il génère. JMeter stocke automatiquement le délai réel dans une variable JMeter appelée T, donc si vous ajoutez un minuteur aléatoire gaussien à l'élément HTTP Proxy Server, vous devez taper $ {T} dans le champ Constant Delay, comme illustré à la figure 4. C'est une autre fonctionnalité pratique qui vous fait gagner beaucoup de temps.

Notez qu'une minuterie retarde les échantillonneurs concernés. Autrement dit, les demandes d'échantillonnage affectées ne sont pas envoyées avant que le délai spécifié ne se soit écoulé depuis la dernière réponse reçue. Par conséquent, vous devez supprimer manuellement le minuteur généré par le premier échantillonneur car le premier échantillonneur n'en a généralement pas besoin.

Avant de démarrer le serveur proxy HTTP, vous devez ajouter un groupe de threads au plan de test, puis, au groupe de threads, ajouter un contrôleur d'enregistrement, où les éléments générés seront stockés. Sinon, ces éléments seront ajoutés directement à WorkBench. De plus, il est important d'ajouter un élément HTTP Request Defaults (un élément Configuration) au contrôleur d'enregistrement, afin que JMeter laisse vides les champs spécifiés par les valeurs par défaut de la requête HTTP.

Après l'enregistrement, arrêtez le serveur proxy HTTP; cliquez avec le bouton droit de la souris sur l'élément Contrôleur d'enregistrement pour enregistrer les éléments enregistrés dans un fichier séparé afin de pouvoir les récupérer ultérieurement. N'oubliez pas de reprendre la configuration du serveur proxy de votre navigateur.

Spécifier les exigences de temps de réponse et valider les résultats des tests

Bien qu'elles ne soient pas directement liées à JMeter, la spécification des exigences de temps de réponse et la validation des résultats des tests sont deux tâches critiques pour les tests de charge, JMeter étant le pont qui les relie.

Dans le contexte des applications Web, le temps de réponse fait référence au temps écoulé entre la soumission d'une demande et la réception du HTML résultant. Techniquement, le temps de réponse doit inclure le temps nécessaire au navigateur pour rendre la page HTML, mais un navigateur affiche généralement la page pièce par pièce, ce qui réduit le temps de réponse perçu. De plus, en général, un outil de test de charge calcule le temps de réponse sans tenir compte du temps de rendu. Par conséquent, à des fins pratiques de test de performance, nous adoptons la définition décrite ci-dessus. En cas de doute, ajoutez une constante au temps de réponse mesuré, disons 0,5 seconde.

Il existe un ensemble de règles bien connues pour déterminer les critères de temps de réponse:

  • Les utilisateurs ne remarquent pas un retard de moins de 0,1 seconde
  • Un retard de moins d'une seconde n'interrompt pas le flux de pensée d'un utilisateur, mais un certain retard est remarqué
  • Les utilisateurs attendent toujours la réponse si elle est retardée de moins de 10 secondes
  • Après 10 secondes, les utilisateurs perdent leur concentration et commencent à faire autre chose

Ces seuils sont bien connus et ne changeront pas puisqu'ils sont directement liés aux caractéristiques cognitives des humains. Bien que vous deviez définir vos exigences de temps de réponse conformément à ces règles, vous devez également les ajuster pour votre application particulière. Par exemple, la page d'accueil d'Amazon.com respecte les règles ci-dessus, mais comme elle préfère un look plus stylistique, elle sacrifie un peu de temps de réponse.

À première vue, il semble y avoir deux façons différentes de spécifier les exigences de temps de réponse:

  • Temps de réponse moyen
  • Temps de réponse absolu; autrement dit, les temps de réponse de toutes les réponses doivent être inférieurs au seuil

La spécification des exigences de temps de réponse moyen est simple, mais le fait que cette exigence ne tienne pas compte de la variation des données est inquiétant. Et si le temps de réponse de 20% des échantillons est plus de trois fois supérieur à la moyenne? Notez que JMeter calcule le temps de réponse moyen ainsi que l'écart type pour vous dans l'écouteur Graph Results.

D'un autre côté, l'exigence absolue de temps de réponse est assez stricte et statistiquement pas pratique. Et si seulement 0,5% des échantillons échouaient aux tests? Encore une fois, cela est lié à la variation d'échantillonnage. Heureusement, une méthode statistique rigoureuse considère la variation d'échantillonnage: l'analyse des intervalles de confiance.

Passons en revue les statistiques de base avant d'aller plus loin.

Le théorème de la limite centrale

Le théorème central limite indique que si la distribution de la population a une moyenne μ et un écart-type σ, alors, pour n suffisamment grand (> 30), la distribution d'échantillonnage de la moyenne d'échantillonnage est approximativement normale, avec moyenne μ moyenne = μ et écart type σ moyenne = σ / √n.

Notez que la distribution de la moyenne d'échantillonnage est normale. La distribution de l'échantillonnage lui-même n'est pas nécessairement normale. Autrement dit, si vous exécutez votre script de test plusieurs fois, la distribution des temps de réponse moyens résultants sera normale.

Les figures 5 et 6 ci-dessous montrent deux distributions normales. Dans notre contexte, l'axe horizontal est la moyenne d'échantillonnage du temps de réponse, décalée de façon à ce que la moyenne de la population soit à l'origine. La figure 5 montre que 90 pour cent du temps, les moyens d'échantillonnage sont dans l'intervalle ± Zσ, où Z = 1,645 et σ est l'écart type. La figure 6 montre le cas de 99%, où Z = 2,576. Pour une probabilité donnée, disons 90 pour cent, nous pouvons rechercher la valeur Z correspondante avec une courbe normale et vice versa.