nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Capture de l'utilisation du matériel lors d'un test de charge Apache JMeter (Intermédiaire)

AaronLopez

Capturer l'utilisation du matériel lors d'un test de charge Apache JMeter

Le débit des transactions mesuré et les temps de réponse sont des données critiques de tout test de charge ArcGIS Enterprise, mais l'utilisation du matériel capturée des machines de déploiement fournit également des informations vitales. Ensemble, ces artefacts de test permettent une analyse appropriée des capacités et des efficacités du Site.

Déterminer qu'une application ou un service de fonctionnalité a atteint un certain niveau de débit est bien, mais confirmer les caractéristiques de scalabilité tout en examinant également l'utilisation du processeur capturée de la charge de travail testée est encore mieux.

Cet article discutera de plusieurs façons de capturer l'utilisation du matériel de la machine. Cette utilisation des ressources est un excellent complément aux résultats d'un test de charge Apache JMeter d'ArcGIS Enterprise et peut aider à approfondir l'analyse. L'article se concentrera sur les scénarios les plus courants utilisant des outils et utilitaires gratuits pour Windows et Linux.

Stratégies de capture

Malheureusement, il n'existe pas de solution unique pour capturer l'utilisation du matériel dans un test de charge. Étant donné le potentiel d'une multitude d'environnements différents (Windows, Linux, Cloud, Kubernetes, Docker, etc...) ou le manque d'accès et permissions requis, il peut y avoir des cas où vous devrez modifier votre stratégie et méthodologie afin de capturer et surveiller les informations d'utilisation de votre matériel pendant que les tests Apache JMeter s'exécutent.

Par exemple, perfmon (par ex. Performance Monitor) est gratuit et inclus avec chaque instance de Microsoft Windows et peut très bien fonctionner lorsque toutes les machines dans l'environnement sont sous Windows. C'est le frontend pour plusieurs technologies Windows (par ex. WMI, DCOM) et toutes ensemble offrent un cadre polyvalent pour surveiller l'utilisation du matériel en "temps réel" avec des graphiques ou en scriptant une capture des ressources vers un fichier de données.

Cependant, perfmon n'est pas disponible pour Linux donc un autre outil (par ex. dstat) serait nécessaire pour capturer l'information équivalente. Bien sûr, même avec une configuration entièrement Windows, des défis peuvent encore survenir avec l'approche perfmon, comme dans les environnements cloud restrictifs. Mais existe-t-il d'autres moyens d'enregistrer ces précieuses données machine ? Nous explorerons la réponse à cette question plus tard dans cet article.

Quelles informations le test de charge doit-il capturer ?

Lorsque des travaux SIG tels que la génération d'une image cartographique ou le calcul d'une requête de service Géotraitement sont envoyés à un déploiement ArcGIS Enterprise, les serveurs qui traitent la réponse utiliseront diverses ressources matérielles pour accomplir la tâche. Idéalement, la majeure partie du travail se fait dans l'unité centrale de traitement (CPU) mais ce n'est pas toujours le cas.

Indépendamment de la technologie utilisée pour surveiller et capturer l'utilisation lors de votre test de charge, il existe quatre catégories principales de compteurs matériels que toutes les machines serveur possèdent :

Processeur
Mémoire
Réseau
Disque

Chaque catégorie dispose d'une variété de métriques pouvant être utilisées pour montrer l'utilisation de cette ressource. Il n'est pas nécessaire (ni recommandé) de capturer toutes les métriques processeur disponibles pendant un test... juste les essentielles. En d'autres termes, celles nécessaires pour répondre aux questions typiques du test de charge ou à l'histoire particulière que vous recherchez.

Typiquement, certaines métriques importantes incluent :

Processeur
- Pourcentage d'utilisation
Mémoire
- Disponible (Mo ou octets)
- Utilisée (Mo ou octets)
- Pourcentage utilisé
Réseau
- Envoyé (Mo ou octets)
- Reçu (Mo ou octets)
Disque
- Pourcentage inactif
- Longueur de la file d'attente
- Lecture (Mo ou octets)
- Ecriture (Mo ou octets)

Note : Si vos serveurs ont plusieurs disques, il est fortement recommandé de collecter sur chacun séparément. En d'autres termes, traitez le lecteur C, le lecteur D et le lecteur E comme des ressources différentes lors de la capture. Il est techniquement possible d'avoir plusieurs périphériques réseau actifs mais ce n'est pas très courant.

L'interface Performance Monitor collectant à partir des différentes métriques matérielles qui ont été ajoutées manuellement (à perfmon) :

Note : Certaines méthodologies pour capturer l'utilisation enregistreront les valeurs en octets tandis que d'autres utilisent mégaoctets. Les deux conviennent, mais il est important de comprendre laquelle est capturée pour l'analyse et la présentation du rapport des données.

Note : Avec le débit des transactions (par ex. transactions/sec) et les temps de réponse des transactions (par ex. secondes), les métriques listées ci-dessus constituent la majeure partie des Indicateurs Clés de Performance (KPIs) d'un test de charge. Les KPIs aident à évaluer et comparer le succès d'un test ou effort particulier par rapport aux objectifs définis du test (par ex. le Plan de Test).

Intervalle d'échantillonnage

Typiquement, un test de charge (avec un focus principal sur la scalabilité) ne dure pas plus d'une heure ou deux. Puisque cela est considéré comme une durée relativement courte, il est logique de capturer l'utilisation du matériel avec un intervalle rapide (par ex. fréquence courte) entre 5 et 10 secondes. Cela aide à garantir qu'assez de données sont obtenues pour effectuer une analyse approfondie. Si l'intervalle de capture est d'une minute ou plus long, certains impacts significatifs sur les ressources matérielles (dus au test) pourraient être manqués.

Note : Un logiciel de surveillance peut déjà fonctionner sur votre réseau qui collecte périodiquement l'utilisation matérielle depuis vos serveurs ArcGIS Enterprise. Si des rapports générés sont disponibles, ils peuvent être utilisés pour l'analyse du test de charge tant que l'intervalle de capture est à une fréquence courte (par ex. 5 à 10 secondes). Pour l'analyse du test de charge, vous êtes intéressé par un bon détail métrique pendant quelques heures plutôt qu'une couverture métrique large sur une journée entière.

La différence entre Capturer et Surveiller

Les termes "capturer" et "surveiller" l'utilisation du matériel sont souvent utilisés indifféremment. Cependant, pour les besoins des tests Apache JMeter, cet article se concentre sur la capture plutôt que sur la surveillance. La différence clé ici est que capturer signifie que nous enregistrons ou sauvegardons l'information pour faciliter l'analyse post-test.

Clients Testeurs (Machines Génératrices de Charge)

Lorsque vous capturez l'utilisation matérielle lors d'un test contre ArcGIS Enterprise, il est recommandé comme bonne pratique d'également mesurer l'utilisation depuis la machine(s) Client Test.
Compréhensiblement, la plupart du focus est mis sur l'observation des ressources serveur, mais le matériel des clients testeurs peut aussi être un goulot d'étranglement. Si ces machines n'ont pas assez de capacité (par ex. processeur, mémoire, réseau ou disque), la capacité à générer une charge contre votre déploiement sera impactée négativement !

Comprenez vos bases serveur

Si vous ne connaissez pas très bien le matériel de votre déploiement ArcGIS Enterprise, il est recommandé d'observer l'utilisation des ressources lorsque le système est inactif. Cette "utilisation" aidera à se faire une idée mentale du meilleur scénario possible. En d'autres termes, à quoi ressemble la machine lorsque le logiciel et les services fonctionnent mais que personne ne s'en sert. Dans un tel scénario, l'activité des ressources dans les quatre catégories matérielles drait être minimale.
Un test de charge n'a pas besoin d'enregistrer cette information sur l'état "inactif" mais c'est bon à savoir à quoi cela ressemble.

Note : Utiliser des outils comme Gestionnaire des tâches (pour Windows) ou top (pour Linux) sont excellents pour obtenir manuellement une vue rapide de l'utilisation des ressources système. Cependant, ils ne sont pas idéaux pour sauvegarder l'utilisation dans toutes les catégories vers un fichier.

Vue Gestionnaire des tâches sur utilisation système (Windows) :

Vue top sur utilisation système (Linux) :

Exemples courants de capture d'utilisation

Utilisation Perfmon (pour capturer utilisation hors test)

Sous réserve que les permissions requises soient disponibles pour votre compte utilisateur sous Windows, perfmon est un des les moyens les plus simples d'enregistrer l'utilisation du matériel pour l'analyse des tests de charge. Performance Monitor (et les technologies associées) peut capturer l'utilisation depuis la machine locale ou plusieurs serveurs distants, simultanément.<\/P>

Note : Pour rappel, les métriques disponibles dans perfmon au sein de chaque groupe matériel sont nombreuses.<\/STRONG><\/FONT>
Il existe également une grande quantité de métriques logicielles qui peuvent être capturées. Mais dans ce cas, moins c'est plus. Seule une petite poignée de compteurs est nécessaire dans la plupart des situations.<\/STRONG><\/FONT><\/P>Comme mentionné précédemment, voici où vous pouvez rencontrer des considérations :<\/P>Le déploiement ArcGIS Enterprise fonctionne sous Linuxperfmon n'est pas disponible pour LinuxLa solution la plus simple est d'utiliser une autre méthodologie pour collecter l'information (discutée plus tard)<\/LI><\/UL><\/LI><\/UL><\/LI>Le déploiement est dans le cloudExécuter erfmon dans le cloud pour collecter depuis d'autres machines de déploiement (dans le cloud) est techniquement possible mais en coulisses il utilise des protocoles réseau qui sont généralement bloqués dans cet environnementLa solution la plus simple ici est d'exécuter perfmon manuellement sur chaque machine cloud et de collecter les sorties générées lorsque le test est terminé<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>Lancer perfmon sous Windows est aussi simple que d'exécuter :<\/P>Exécuter --> perfmon<\/LI><\/UL>À partir de là, vous pouvez ajouter chaque machine ainsi que chaque métrique matérielle et compteur respectifs. Bien que cela soit très puissant, cela peut prendre du temps et être potentiellement sujet à des erreurs de frappe !<\/P>Au lieu de cela, la stratégie recommandée pour cette méthodologie est d'utiliser un script PowerShell où tous ces éléments sont prédéfinis.<\/P>Ce qui suit recueillera les principales métriques perfmon (déjà définies) des quatre catégories matérielles principales et le fera pour quatre machines différentes (que vous pouvez spécifier) :<\/LI><\/UL> <\/P># =============================================================================== # Mis à jour : 2022-08-02 # Nom du fichier : ps_get_all_continuous.ps1 # Version : 0.1.0 # Description : Collecte continue de diverses métriques et enregistrement des valeurs (binaires) dans un fichier # Notes : Il est recommandé de démarrer la collecte des métriques 20 secondes avant le début du test # car l'initialisation des compteurs peut prendre un certain temps # =============================================================================== Write-Output -InputObject 'Collecte de toutes les métriques (continue)...' # Variables # Compteur(s) Perfmon Windows $counters = "Processor(_Total)\% Processor Time","Memory\Available MBytes","Memory\Committed Bytes","Memory\% Committed Bytes In Use","Network Interface(*)\Bytes Received/sec","Network Interface(*)\Bytes Sent/sec","LogicalDisk(_Total)\% Idle Time","LogicalDisk(_Total)\Disk Read Bytes/sec","LogicalDisk(_Total)\Disk Write Bytes/sec" # Machines à collecter $computers = @('server1.domain.com','server2.domain.com','server3.domain.com','server4.domain.com') # Temps en secondes entre chaque collecte d'échantillon $sampleinterval = 10 $date = (Get-Date) $dyndate = '{0:yyyyMMddTHHmmss}' -f $date # 20220303T140044 # Nom du fichier $filename = "perfmon_all_continuous" # Type de fichier de sortie (choix : blg, csv ou tsv) $outputfiletype = "blg" # Fichier de sortie $outputfile = '{0}_{1}.{2}' -f $filename, $dyndate, $outputfiletype # Get-counter Write-Output -InputObject ('Date et heure de début : {0}' -f $date) Get-counter -Computername $computers -Counter $counters -Continuous -Sampleinterval $sampleinterval | Export-counter -Force -FileFormat $outputfiletype -Path $outputfile <\/code><\/pre> <\/P><UL><LI>Les métriques sont collectées toutes les 10 secondes jusqu'à ce que vous appuyiez sur Ctrl-C dans la fenêtre PowerShell<\/U>. Les informations sont enregistrées dans un fichier au format binaire que vous pouvez ouvrir sous Windows (pour une analyse ou transformation ultérieure) :<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49356iC6B4C3B9199D2CF8\/capturehardware_powershell_start_output.png" role="button" title="capturehardware_powershell_start_output.png" alt="capturehardware_powershell_start_output.png" \/><\/P>Note : Il est recommandé de démarrer ce script Powershell environ 20 ou 30 secondes avant<\/U> le début du test de charge car l'initialisation des compteurs n'est pas immédiate et prend un moment.<\/FONT><\/STRONG><\/P><UL><LI>Vous pouvez ouvrir le fichier *.blg à tout moment pendant la capture, mais les dernières informations ne sont pas vidées et enregistrées dans le fichier tant que vous n'avez pas appuyé sur Ctrl-C dans la fenêtre PowerShell où le script s'exécute.<\/LI><LI>Un double-clic pour ouvrir le fichier *.blg devrait ressembler à ce qui suit :<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49377i9D7D47D522AD17A4\/capturehardware_powershell_results.png" role="button" title="capturehardware_powershell_results.png" alt="capturehardware_powershell_results.png" \/><\/P>Le résultat final est une sortie très similaire à ce que nous avons capturé. Cependant, dans ce cas, le processus a été automatisé (ce qui est une bonne chose).<\/SPAN><\/P>Depuis cette interface dans Performance Monitor, vous pouvez sélectionner/désélectionner des métriques pour une isolation spécifique, exporter le graphique en image, enregistrer les données brutes dans un autre format comme CSV, ou effectuer une analyse d'utilisation depuis toutes les machines collectées. Assez puissant !<\/SPAN><\/P>Note : Les scripts Performance Monitor ne s'intègrent pas directement dans JMeter. <\/STRONG><\/FONT><\/SPAN><\/P>Note : Pour les déploiements cloud, vous devrez peut-être exécuter manuellement le script perfmon sur chaque serveur respectif.<\/STRONG><\/FONT><\/SPAN><\/P><H3 id="toc-hId--464400263">Utilisation de dstat (Pour capturer l'utilisation en dehors du test de charge)<\/H3>dstat est un outil en ligne de commande gratuit (écrit par dag@wieers.com) disponible pour (ou avec) la plupart des distributions Linux qui capture (et surveille) l'utilisation matérielle. Bien que l'utilitaire n'ait pas été mis à jour depuis plusieurs années, il est assez robuste et facile à script.<\/P><UL><LI>Sortie terminale dstat sans options :<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49381i3426B23A73682927\/capturehardware_dstat_monitor.png" role="button" title="capturehardware_dstat_monitor.png" alt="capturehardware_dstat_monitor.png" \/>Ce qui suit s'exécutera sur votre serveur Linux et capturera l'utilisation matérielle dans un fichier csv toutes les 5 secondes jusqu'à ce que vous l'arrêtiez manuellement avec Ctrl-C<\/U>:<\/P><UL><LI>[gisadmin@pesrv04 ~]$ dstat -tTcmn --disk-util -d --nocolor --noheaders --output dstat_20220823.csv 5<\/STRONG></LI></UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49383i12F99873FC093EA3\/capturehardware_dstat_capture.png" role="button" title="capturehardware_dstat_capture.png" alt="capturehardware_dstat_capture.png" \/>Note : Avec dstat, l'utilisation processeur capturée est le "pourcentage de temps inactif", pas le pourcentage d'utilisation. Pour obtenir le pourcentage d'utilisation, soustrayez la valeur de 100. Cependant, l'utilisation du disque est exprimée en pourcentage d'utilisation. De plus, la sortie ci-dessus inclut un format de présentation donc les valeurs brutes (non affichées) pour mémoire, réseau et disque sont enregistrées en octets.<\/STRONG>Note : Les scripts dstat doivent être exécutés manuellement et séparément sur chaque machine Linux du déploiement. Ils ne s'intègrent pas directement dans JMeter. Une fois un test de charge terminé et les scripts arrêtés, les fichiers CSV peuvent être collectés et analysés (par exemple tracés ou graphiques dans un programme tableur).<\/STRONG><H3 id="toc-hId-2023112570">Utilisation d'Apache JMeter (Pour capturer l'utilisation directement depuis le test de charge)<\/H3>Bien qu'il comporte quelques étapes supplémentaires (ainsi que ses propres obstacles) par rapport aux scripts perfmon et dstat, utiliser Apache JMeter pour capturer l'utilisation matérielle présente un avantage principal :<\/P><UL><LI>Cohérence. Le même plan de test JMeter peut être utilisé pour capturer les mêmes métriques matérielles depuis Windows et Linux (et Mac)<UL ><LI>Cela est réalisé grâce à plusieurs logiciels gratuits :<UL ><LI>L'<A href="https:\/\/jmeter-plugins.org/wiki/PerfMon/" target="_blank" rel="noopener nofollow noreferrer">extension jp@gc - PerfMon Metrics Collector</A> ajoutée à JMeter  <UL ><LI>Ce composant sert à définir quelles métriques collecter et depuis quelles machines< / LI >< / UL >< / LI >< LI >L'<A href= "https:\/ \/github.com\ /undera\ /perfmon-agent\ /blob\ /master\ /README.md " target= "_blank " rel= "noopener nofollow noreferrer " >Outil PerfMon Server Agent</A> qui s'exécute dans un environnement Java Runtime Environment (JRE) sur chaque serveur du déploiement <UL ><LI >Ce composant effectue la collecte réelle sur chaque serveur et renvoie les données à JMeter< / LI >< / UL >< / LI >< / UL >< / LI >< / UL >< / LI >< / UL >Le composant jp@gc - PerfMon Metrics Collector peut être facilement ajouté au plan de test via le gestionnaire de plugins JMeter (trouvé sous "PerfMon (Servers Performance Monitoring):< img src= "https:\/ \/us.v-cdn.net\ /6038851\ /uploads\ /images\ /49709i9536381D99067E93\ /capturehardware_jmeter_pluginmanager.png " role= "button " title= "capturehardware_jmeter_pluginmanager.png " alt= "capturehardware_jmeter_pluginmanager.png " \/ >Le Le composant PerfMon Server Agent est relativement facile à ajouter mais nécessite quelques étapes supplémentaires pour bien fonctionner.<\/SPAN><\/P>Note : En raison d'un bug dans la bibliothèque sigar-amd64-winnt, le ServerAgent crashe<\/EM> si vous utilisez la bibliothèque prête à l'emploi avec un JDK ou JRE supérieur à la version 8. La solution consiste à patcher la bibliothèque ou à utiliser une version 8 JRE à jour.<\/STRONG><\/FONT><\/P><A href="https:\/\/www.openlogic.com\/openjdk-downloads" target="_self" rel="nofollow noopener noreferrer">OpenLogic<\/A> fournit des versions gratuites et périodiquement mises à jour de OpenJDK v8 (et JRE) à télécharger pour Windows, Linux et Mac. Bien que le JDK fonctionne, le JRE est recommandé dans ce cas car c'est un package plus léger à télécharger tout en fournissant l'environnement nécessaire pour exécuter l'agent. <\/FONT><\/P>Note : Le JRE 32 bits ou 64 bits fonctionnera pour le ServerAgent.<\/STRONG><\/FONT><\/P>Note : Le JDK ou JRE OpenLogic peut également être utilisé pour exécuter Apache JMeter lui-même.<\/STRONG><\/FONT><\/P><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49406iEBD98A1C9C85F57D\/capturehardware_openlogic_download.png" role="button" title="capturehardware_openlogic_download.png" alt="capturehardware_openlogic_download.png" \/><\/span><\/FONT><\/P><UL><LI>Le ServerAgent et le JRE OpenLogic décompressés dans le même dossier :<\/SPAN><\/FONT><\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49499i1001834053E61544\/capturehardware_openlogic_serveragent_explorer.png" role="button" title="capturehardware_openlogic_serveragent_explorer.png" alt="capturehardware_openlogic_serveragent_explorer.png" \/><\/span><\/FONT><\/FONT><\/P><UL><LI> Le JRE OpenLogic déplacé dans le dossier ServerAgent :<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49500i9E7477A4EACB100A\/capturehardware_openlogic_serveragent_jre.png" role="button" title="capturehardware_openlogic_serveragent_jre.png" alt="capturehardware_openlogic_serveragent_jre.png" \/><\/span><\/FONT><\/FONT><\/P><UL><LI>Ouvrez le fichier startAgent.bat dans un éditeur et mettez-le à jour avec le nom du répertoire JRE qui a été copié dans le dossier ServerAgent :<\/LI><\/UL> <\/P><pre class="lia-code-sample language-csharp"><code> off\n\nset JAVAPATH=.\\openlogic-openjdk-jre-8u342-b07-windows-64\\bin\n%JAVAPATH%\\java -jar %0\\..\\CMDRunner.jar --tool PerfMonAgent %*<\/code><\/pre> <\/P><UL><LI>Enregistrez les modifications<\/LI><LI>Le dossier C:\JMeterAgent\ServerAgent-2.2.3 contient maintenant un ServerAgent autonome qui peut être copié sur les machines appropriées pour collecter leur utilisation matérielle<\/LI><LI>Pour démarrer l'agent sous Windows<\/STRONG>, double-cliquez sur startAgent.bat<UL><LI>L'agent s'ouvrira dans une fenêtre de commande :<\/LI><\/UL><\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49501iB7B6D67885E49A9C\capturehardware_serveragent_listening.png" role="button" title="capturehardware_serveragent_listening.png" alt="capturehardware_serveragent_listening.png" \/><UL><LI>L'agent ne commencera pas à "collecter" des métriques tant qu'il n'aura pas reçu d'instructions du Plan de Test Apache JMeter <UL><LI>Par défaut, l'agent et JMeter communiqueront entre eux via les ports TCP et UDP 4444<\/LI></UL></LI></UL>Note : Le collecteur de métriques jp@gc - PerfMon utilise le nom "perfmon" mais n'utilise pas<\U> réellement la technologie Windows Performance Monitor.<\STRONG><H1 id = "toc-hId--737670810">Le plan de test SampleWorldCities <\SPAN> avec prise en charge de la collecte des métriques</H1 ><UL ><LI >Pour télécharger le plan de test Apache JMeter utilisé dans cet article, voir : <A href = "https://community.esri.com/ccqpr47374/attachments/ccqpr47374/implementing-arcgis-blog/355.14/1/sampleworldcities5.zip " target = "_self">sampleworldcities5.zip</A >  </LI ><LI >L'ouverture du plan de test dans Apache JMeter devrait ressembler à ce qui suit :<UL class = "lia-list-style-type-circle"><LI >Ajustez les variables définies par l'utilisateur pour correspondre à votre environnement<UL ><LI >Ce test définit quatre machines différentes pour collecter l'utilisation matérielle de :<UL ><LI >Un adaptateur web<UL ><LI >Les requêtes sont également envoyées à ce point de terminaison</LI ></UL ></LI ><LI >Un serveur ArcGIS</LI ><LI >Un Portal for ArcGIS</LI ><LI >Le client de test (la machine exécutant JMeter)<UL ><LI >Le nom d'hôte de cette machine est détecté automatiquement par JMeter lors de l'exécution du test</LI ></UL ></LI ></UL ></LI ></UL ></LI ></UL ></LI ></UL ><img src = "https://us.v-cdn.net/6038851/uploads/images/49509iFF0B49BC3452FB54/capturehardware_jmetertestplan_userdefinedvariables.png " role = "button " title = "capturehardware_jmetertestplan_userdefinedvariables.png " alt = "capturehardware_jmetertestplan_userdefinedvariables.png " /><H2 id = "toc-hId-1878924742">Composants du plan de test</H2 >L'extension jp@gc - PerfMon Metrics Collector est le seul élément d'intérêt ici car ce test est pratiquement identique aux plans de test des articles précédents pour SampleWorldCities.<H3 id = "toc-hId-200552998">Extension jp@gc - PerfMon Metrics Collector</H3 >Comme mentionné précédemment, l'extension indique à chaque agent en cours d'exécution ce qu'il doit collecter. Le plan de test disponible dans cet article a déjà ajouté les compteurs pour chacune des quatre principales catégories matérielles. Note : Les paramètres des métriques fonctionneront pour Linux et Mac. Cependant, les métriques Disks IO dans l'extension sont configurées pour collecter sur le lecteur C (par exemple C\:\) qui n'existe pas sous Linux. Cela devra être modifié en \/.<img src = "https://us.v-cdn.net/6038851/uploads/images/49510iD61C8B558F5AFD10/capturehardware_jmetertestplan_perfmonmetricscollector.png " role = "button " title = "capturehardware_jmetertestplan_perfmonmetricscollector.png " alt = "capturehardware_jmetertestplan_perfmonmetricscollector.png " /><H2 id = "toc-hId--1735984184">Valider la connectivité entre JMeter et ServerAgent</H2 >Démarrez le test depuis l'interface graphique en cliquant sur le bouton lecture (triangle vert)<UL ><LI >Si tous les ServerAgents sont en cours d'exécution et accessibles sur toutes les machines prévues dans le déploiement ArcGIS Enterprise, ils devraient pouvoir collecter l'utilisation et renvoyer les informations au plan de test</LI ><LI >Au fur et à mesure que JMeter reçoit ces informations, il les affichera dans l'onglet Graphique<UL ><LI >Laissez cela collecter pendant quelques secondes pour valider la connectivité puis arrêtez le test</LI ></UL ></LI ></UL ><img src = "https://us.v-cdn.net/6038851/uploads/images/49512iACE9249861C62895/capturehardware_jmetertestplan_validateconnectivity.png " role = "button " title = "capturehardware_jmetertestplan_validateconnectivity.png " alt = "capturehardware_jmetertestplan_validateconnectivity.png " />Note : Lorsque le test est exécuté depuis la ligne de commande, le nom du fichier contenant les données des métriques collectées sera basé sur des variables dans le script bat qui définissent le fichier « results_ ». Une fois le test terminé, vous pouvez utiliser cet élément « jp@gc - PerfMon Metrics Collector » pour charger les valeurs brutes et soit isoler certains compteurs soit générer des images graphiques. Ce fichier commencera par la chaîne « perfmon_ ». Les fichiers results et perfmon se terminent tous deux par une extension *.jtl mais sont simplement des fichiers CSV.<H1 id = "toc-hId-622445930">Exécution du test</H1 >Le test de charge doit être exécuté de la même manière qu'un plan de test typique JMeter.Voir le script runMe_withP.bat inclus avec le projet sampleworldcities5.zip pour un exemple sur comment exécuter un test comme recommandé par l'équipe Apache JMeter. <UL ><LI >Le script runMe_withP.bat contient une variable jmeterbin qui devra être définie à la valeur appropriée pour votre environnement</LI ><LI >Ce script contient un peu plus de logique que runMe.bat trouvé dans d'autres articles sur les plans de test<UL ><LI >Cette logique supplémentaire a été ajoutée afin que le fichier résultats et celui contenant les données matérielles collectées se terminent par le même nom d'exécution</LI ></UL ></LI ><LI >Contenu du script runMe_withP.bat :</LI ></UL > <pre class="lia-code-sample language-csharp"><code>echo off\nrem Exécution scriptée du plan de test JMeter\nrem Utilisation d'ApacheJMeter.jar pour invocation\nrem\nrem 2022/08/25.1\nrem \nrem Avec variable d'environnement pour support JMeter (pour extension PerfMon)\n\n\nrem ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nrem *** Variables ***\n\nrem Définir la mémoire JMeter min/max à 4 Go (ajustez selon les ressources de votre client de test)\nset heap=-Xms4g -Xmx4g -xyz:MaxMetaspaceSize=256m\n\nrem Emplacement de %JAVA_HOME%\\bin\nset javadir=%JAVA_HOME%\\bin\n\nrem Emplacement du binaire Apache JMeter\nset jmeterbin=C:\apache-jmeter-5.5\bin\n\nrem Emplacement du dossier racine du Plan de Test JMeter (par exemple le dossier où se trouve le Plan de Test) set projectdir=%~dp0 rem Nom du Plan de Test JMeter (sans l'extension de fichier JMX) set testname=sampleworldcities5 rem Chaîne ajoutée au fichier de résultats de chaque exécution de test set runname=testrun1 rem Paramètres du proxy rem set proxyhost=http:\/\/localhost rem set proxyport=8888 rem ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ rem *** Démarrez vos moteurs *** color 20 rem Définir une variable d'environnement à référencer dans le test (par exemple ${__P(env.run)}) set jvm_args="-Denv.runname=%testname%_%runname%" echo on rem *** Test démarré *** %javadir%\java.exe --illegal-access=warn %jvm_args% %heap% -jar %jmeterbin%\ApacheJMeter.jar -Jjmeter.save.saveservice.autoflush=false -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 décommentez selon les besoins rem -H %proxyhost% -P %proxyport% ^ rem *** Test terminé *** echo off color 40 ping localhost -n 5 color 07

Note : Il est toujours recommandé de coordonner l'heure de début et la durée du test de charge avec le personnel approprié de votre organisation. Cela garantit un impact minimal pour les utilisateurs et autres collègues qui peuvent également avoir besoin d'utiliser votre Site ArcGIS Enterprise sur site. De plus, cela aide à prévenir le bruit système provenant d'autres activités et utilisations qui pourraient "polluer" les résultats du test.

Note : Pour plusieurs raisons, il est fortement conseillé de ne jamais effectuer de test de charge sur les services fournis par ArcGIS Online.

Guide Méthodologique Général

Ce guide n'a pas pour but d'être exhaustif en couvrant tous les scénarios de capture d'utilisation matérielle.

Scénario #1
- Serveurs
  - Windows
- Environnement
  - Sur site
- Machine Collectrice (Client de Test)
  - Windows
- Description
  - Capture de l'utilisation Windows depuis Windows
- Difficulté
  - Facile/Modérée
- Méthodologie Recommandée
  - Windows Perfmon (via script PowerShell)

Scénario #2
- Serveurs
  - Windows/Linux
- Environnement
  - Sur site
- Machine Collectrice (Client de Test)
  - Windows
- Description
  - Capture de l'utilisation Windows/Linux depuis Windows
- Difficulté
  - Modérée
- Méthodologie Recommandée
  - JMeter Perfmon Extension and ServerAgent

Scénario #3
- Serveurs
  - Linux
- Environnement
  - Sur site
- Machine Collectrice (Client de Test)
  - Windows/Linux
- Description
  - Capture de l'utilisation Linux depuis Windows/Linux
- Difficulté
  - Facile/Modérée
- Méthodologie Recommandée
  - dstat command or script

Scénario #4
- Serveurs
  - Windows/Linux
- Environnement
  - Cloud
- Machine Collectrice (Client de Test)
  - Windows
- Description
  - Capture de l'utilisation Windows/Linux depuis Windows
- Difficulté
  - Modérée
- Méthodologie Recommandée
  - Cloud Watch/Azure Monitor (non couvert dans cet Article)

Scénario #5
- Serveurs
  - Windows
- Environnement
  - Cloud
  ;
  Défis Courants dans la Collecte d'Utilisation
  ;
  ; La capture de l'utilisation matérielle des machines déployées pour un test de charge est une bonne pratique mais ce n'est pas toujours possible.
  ;
  ; Les défis les plus typiques sont :
  ;
  - ; Permissions
    - ; Le plus courant
    - ; Ne pas avoir obtenu l'accès ou la capacité à capturer l'utilisation des serveurs distants est le défi le plus courant
    ;
  - ; Environnement/Emplacement
    - ; Collecter l'utilisation des machines sur le réseau local est une chose, collecter l'utilisation des machines dans le cloud en est une autre
    ;
  - ; Système d'Exploitation
    - ; Parfois, le système d'exploitation présente ses propres *obstacles* pour capturer l'utilisation
    ;
  - ; Technique
    - ; Certains environnements (par exemple Kubernetes/Docker) peuvent ne pas disposer des mêmes API pour collecter l'utilisation qu'une machine traditionnelle (physique ou virtuelle)
    ;
  ;
  Réflexions Finales
  ;
  ; En résumé, il existe plusieurs façons de capturer les informations d'utilisation matérielle des machines dans un déploiement ArcGIS Enterprise pour analyser avec vos résultats de test de charge. La meilleure façon de la capturer... c'est toute méthode qui fonctionne le mieux où vous pouvez rapidement enregistrer les informations et les utiliser pour une analyse efficace.
  ;
  ; Bien qu'aucun article ne puisse couvrir toutes les situations, environnements et scénarios, celui-ci liste plusieurs méthodologies pour capturer ces données pour les cas courants.
  ;

Trouver plus de publications taguées avec

Operational Support

Strategy & Planning

Architecture & Security

Réponses

AaronLopez

Hi @ErickTGG,
Any observability tool could be used to capture operation data like CPU and memory usage from a performance/load test. And, if these reports and filters already exist and can be consumed that is definitely a good strategy.

One thing to keep in mind is that by default, many monitoring tools capture metrics for long term analysis. A common polling rate is every 1 minute or 5 minutes since they are expecting to store a lot of data (and this frequency can help with the manageability and scalability of that system).

As such, that "lower" resolution is generally not ideal for examining the impact of a load test. A typical load test runs for 1-- 2 hours. For such a short duration, higher capture intervals like 5, 10, or 20 seconds, are usually favored so a more detailed impact on the deployment's resources can be seen. This might be adjustable with most monitoring tools...not sure.
In cases where this higher resolution is not an option or maybe there is no monitoring tool even available, having the testing framework capture this type of data can be extremely valuable for the analysis.

Hope that helps.
Aaron

ErickTGG

Hey - Any reason why you haven't covered anything here with ArcGIS Monitor?

Is it that we can just create some filters in ArcGIS Monitor to view the same metrics?

Rejoignez la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.