Pourquoi exécuter les plans de test en mode ligne de commande ?
La raison principale pour exécuter un test de charge en mode ligne de commande (CLI) et non via le mode GUI est que ce dernier peut diminuer les capacités de JMeter. Utiliser le GUI pour exécuter le test peut consommer du CPU et de la mémoire supplémentaires, ce qui peut impacter négativement les résultats du test. L'environnement en mode CLI est le choix optimal pour l'exécution du test et est la méthodologie recommandée par l'équipe Apache JMeter.
Exécuter un test via une fenêtre de commande peut sembler un peu old school, mais c'est toujours très efficace.
Vérification de la liste de contrôle pré-test
Il est une bonne pratique de test d'utiliser une liste de contrôle pré-test pour aider à tirer le meilleur parti de votre temps de test.
Les éléments recommandés dans la liste incluent :
- Coordonner l'heure de début et la durée du test de charge avec le personnel administratif
- Assure un impact minimal du test sur les utilisateurs et autres collègues pour le site ArcGIS Enterprise
- Aide à prévenir le system noise provenant d'autres activités et utilisations qui pourraient "polluer" les résultats du test
- Lors du test d'un service ArcGIS traditionnel (par exemple dédié), assurez-vous que les instances minimales et maximales sont correctement définies
- Ceci est nécessaire si votre objectif de test est d'essayer de comprendre le débit maximal réalisable par le service
- Pour un débit maximal, une règle générale est de définir les instances maximales au nombre de cœurs CPU
- Pour des performances prévisibles, définissez les instances minimales au nombre d'instances maximales
- L'ajustement des instances provoquera un redémarrage du service (planifiez en conséquence)
- L'augmentation des instances minimales d'un service nécessitera plus de mémoire physique sur la machine ArcGIS Server
- Si le plan de test contient un Listener comme View Results Tree, assurez-vous de le désactiver depuis le GUI
- L'exécution des Listeners peut augmenter la consommation des ressources du client de test et potentiellement impacter le test
- Validez le Thread Group pour la logique de charge progressive et la durée du test
- Si le test est programmé pour une fenêtre spécifique, assurez-vous que le test sera configuré pour s'exécuter pendant la durée prévue
- S'assurer que le niveau de journalisation ArcGIS Server n'est pas réglé sur DEBUG ou VERBOSE.
- Bien que ces niveaux de journalisation puissent être utiles pour résoudre des problèmes, ils peuvent impacter les performances et la scalabilité des services testés
Présentation du script batch
Puisque la ligne de commande est utilisée pour exécuter le test de charge Apache JMeter, il est avantageux d'assembler les actions et la préparation de l'environnement dans un script batch (par exemple un fichier *.bat sous Windows). Cela favorise la répétabilité et la maintenance.
Variables
L'utilisation des variables est un moyen pratique d'améliorer la maintenance d'un script. Bien que coder en dur les valeurs soit techniquement correct, cela peut nuire à la lisibilité si les chemins pour certains éléments sont très longs. Les sections suivantes sont les principaux composants où notre batch utilisera des variables.
Mémoire
Par défaut, Apache JMeter (version 5.4.1) fonctionne avec une mémoire minimale et maximale de 1 Go. Cela est suffisant pour des tests simples exécutés sur du matériel ancien, mais certains tests nécessitent une logique plus complexe ou plusieurs fichiers de données et plus de mémoire pourrait être nécessaire pour garantir que les résultats des tests ne soient pas impactés.
Note : De nombreux tests de charge se concentrent sur l'utilisation des ressources matérielles du serveur. Cependant, les capacités du client de test peuvent aussi être un goulot d'étranglement limitant la capacité à atteindre les objectifs du test.
Augmenter la mémoire par défaut peut se faire facilement avec ce qui suit :
- set heap=-Xms4g -Xmx4g -xyz:MaxMetaspaceSize=256m
Chemins JMeter et projet
Nous voulons indiquer au script batch où trouver Apache JMeter et notre plan de test.
Définir le chemin vers le dossier bin de JMeter est simple :
- set jmeterbin=C:\apache-jmeter-5.4.1\bin
C'est aussi le dossier projet (créé manuellement) où réside le fichier jmx (par exemple, le plan de test)
- set projectdir=C:\JMeter Tests\sampleworldcities3
Pour plus d'extensibilité, une variable est créée pour le nom du fichier jmx séparément du dossier projet (sans l'extension jmx même s'ils ont le même nom)
- set testname=sampleworldcities3
Pour plus de commodité, une variable est créée qui sera ajoutée à chaque exécution. Pour plusieurs raisons, un test typique peut être exécuté plusieurs fois, chacun ayant une option légèrement différente activée dans le plan de test. Cela aide à suivre différentes exécutions du même test.
Exécution du test et commutateurs
Grâce à l'utilisation des variables mentionnées ci-dessus, l'exécution de JMeter avec un plan de test passé en commutateur ligne de commande peut être facilement revue en quelques lignes :
%jmeterbin%\jmeter -n -f -t "%projectdir%\%testname%.jmx" ^
-l "%projectdir%\results\results_%testname%_%runname%.jtl" ^
-j "%projectdir%\logs\debug_%testname%_%runname%.log" ^
-e -o "%projectdir%\reports\%testname%_%runname%" ^
- Le commutateur -n exécute JMeter en mode ligne commande
- Le commutateur -t "path_to_jmx" indique à JMeter où trouver sur le système fichier le fichier jmx.
- Le commutateur -l "path_to_jtl" indique à JMeter où enregistrer les échantillons, c'est le fichier résultats et l'artefact le plus important du déroulement du test.
- Le commutateur -j "path_to_log" indique où stocker le journal d'exécution JMeter (par exemple informations environnementales). Le commutateur -e indique à JMeter de générer un rapport (tableau de bord) une fois que le test est terminé.
- Le commutateur -o "path_to_report_folder" indique à JMeter où générer le rapport (tableau de bord).
- Le commutateur -f indique à JMeter d'effacer forcé les fichiers résultats existants et dossier rapport s'ils sont présents avant démarrage du test. Modifier la variable "runname" dans le script est la façon la plus simple d'assurer qu'un nouveau fichier résultats et rapport soient créés à chaque exécution.
- Le caractère caret ou ^ est un caractère "escape" ajouté au script batch Windows afin que le caractère suivant (saut ligne) soit interprété comme ordinaire. Cela aide à la lisibilité.
Mise en œuvre complète
Le script batch complet est comme suit :
echo off
rem Exécution scriptée du plan de test JMeter
rem Utilisation jmeter.bat pour invocation
rem
rem 2021/06/07.1
rem
rem ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
rem *** Variables ***
rem Définir mémoire JMeter min/max à 4GB (ajuster selon ressources client)
set heap=-Xms4g -Xmx4g -xyz:MaxMetaspaceSize=256m
rem Emplacement %JAVA_HOME%\bin (non utilisé actuellement)
rem set javadir=C:\jdk-16.0.1\bin
rem Emplacement bin Apache JMeter
set jmeterbin=C:\apache-jmeter-5.4.1\bin
rem Emplacement dossier racine plan Test JMeter (ex : dossier contenant plan Test)
set projectdir=C:\JMeter Tests\sampleworldcities3
rem Nom plan Test JMeter (sans extension JMX)
set testname=sampleworldcities3
rem Chaîne ajoutée au fichier résultats à chaque exécution
set runname=run1
rem ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
echo on
rem *** Test démarré ***
%jmeterbin%\jmeter -n -f -t "%projectdir%\%testname%.jmx" ^
-l "%projectdir%\results\results_%testname%_%runname%.jtl" ^
-j "%projectdir%\logs\debug_%testname%_%runname%.log" ^
-e -o "%projectdir%\reports\%testname%_%runname%" ^
rem *** Test terminé ***
echo off
Exécution du test de charge
Pour les premières exécutions de votre test, il est recommandé d'exécuter depuis une fenêtre commande déjà ouverte. Ainsi, s'il y a des problèmes immédiats lors d'invocation des commandes dans le script batch, ils resteront affichés à l'écran pour être corrigés plus facilement (par exemple une faute de frappe).
- Sous Windows, vous pouvez ouvrir une fenêtre Invite de commandes en cliquant sur Démarrer puis en tapant cmd.
- Dès que cette fenêtre apparaît, saisissez le chemin vers votre script batch :
- "C:\JMeter Tests\sampleworldcities3\runMe.bat", appuyez sur Entrée
- Le script s'exécutera pendant la durée configurée puis retournera à l'invite commande
L'exécution en mode ligne commande ne fournir à la console des statistiques en temps réel de l'exécution du test. Une telle fonctionnalité peut être obtenue mais n'est pas couverte dans cet Article.<\/P>
Artefacts de Test<\/H1>Les artefacts de test sont des éléments créés à partir du test de charge qui peuvent être utilisés pour l'analyse. Des éléments comme le rapport et les fichiers JMeter Text Logs (JTL) qui contiennent les résultats bruts du test sont généralement les plus importants à conserver. Le journal d'exécution peut également être utile car sa liste peut être utilisée pour confirmer la mémoire configurée de l'environnement pour l'exécution du test ainsi que les mises à jour indiquant quelle étape était exécutée et quand. Après plusieurs exécutions du même test, où un nom d'exécution différent dans le script a été utilisé, il est facile de se retrouver avec de nombreux fichiers jtl et dossiers de rapport. C'est là que suivre la stratégie de test consistant à utiliser un dossier projet pour la gestion est essentiel.<\/P>Note : Le rapport généré par JMeter est basé sur HTML et JavaScript. Si certains composants du rapport sont vides ou ne semblent pas s'afficher, essayez d'ajuster les paramètres de sécurité du navigateur ou ouvrez-le dans un autre navigateur, si disponible.<\/STRONG><\/FONT><\/P>La page initiale et la section Temps de Réponse au Fil du Temps d'un rapport généré par JMeter<\/FONT><\/LI><\/UL>
<\/span><\/P>
<\/span><\/P>Pour télécharger le Plan de Test Apache JMeter utilisé dans cet Article, voir : <\/SPAN>sampleworldcities3.zip<\/A><\/P>Ce test nécessite que le plugin Custom Thread Groups soit installé dans JMeter.<\/P>
