Se préparer à l'inondation : Votre GIS Server coulera-t-il ou flottera-t-il ?

RandallWilliams

<\/HEAD>J'ai récemment effectué des tests de charge sur ArcGIS Server, et il m'est venu à l'esprit que, bien que nous disions souvent aux utilisateurs d'utiliser des outils de test de charge avant de rendre une application SIG publique, nous n'entrons pas trop dans les détails sur la manière de configurer ces tests. Dans ce blog, je vais décrire comment configurer et exécuter des tests en utilisant un outil Java open source appelé JMeter pour aider à tester la charge de votre installation et application GIS Server.Tout d'abord, qu'est-ce que JMeter<\/A> ?<\/STRONG>

D'après le site web de JMeter :

1'application de bureau Apache JMeter<\/STRONG>122 est un logiciel open source, une application 100 % pure Java conçue pour tester la charge du comportement fonctionnel et mesurer les performances. Elle a été initialement conçue pour tester les applications Web mais s'est depuis étendue à d'autres fonctions de test. Que puis-je faire avec ? <\/STRONG>

Apache JMeter peut être utilisé pour tester les performances sur des ressources statiques et dynamiques (fichiers, Servlets, scripts Perl, objets Java, bases de données et requêtes, serveurs FTP et plus). Il peut être utilisé pour simuler une charge importante sur un serveur, un réseau ou un objet afin de tester sa résistance ou analyser les performances globales sous différents types de charge. Vous pouvez l'utiliser pour faire une analyse graphique des performances ou pour tester le comportement de votre serveur\/script\/objet sous une charge concurrente importante."

C'est très bien, mais voici ce que je<\/STRONG> fais avec :

J'utilise JMeter pour simuler la charge d'un groupe d'utilisateurs travaillant simultanément avec ArcGIS Server. Ces utilisateurs simulés sont SURHUMAINS, car mes tests JMeter envoient des requêtes à raison de centaines voire milliers par minute. J'ai récemment testé l'utilisation mémoire de la version 10.1 après avoir envoyé littéralement plus de 100 millions de requêtes de fonctionnalités à ArcGIS Server sur une AMI pendant environ une semaine. (Vous serez heureux d'apprendre que j'ai constaté que la mémoire était bien gérée pendant ce test).

Rappelez-vous que JMeter n'est pas un navigateur. Bien que le serveur exécute toute opération que vous lui soumettez, JMeter ne rendra pas la réponse graphiquement. Vous obtenez les résultats sous forme d'une notification PASS\/FAIL.

Bien. Mettons cela ensemble et lançons un test. Permettez-moi de vous guider.De quoi ai-je besoin ?<\/STRONG>

Bonne question. Vous aurez besoin :De votre machine ArcGIS Server. Vous pouvez tester Java ou .Net, sur n'importe quel OS supporté.<\/LI>D'un endroit pour installer JMeter. Cela peut être la même machine que votre ArcGIS Server, mais je trouve que vous obtiendrez des résultats plus précis si JMeter est installé ailleurs. En effet, lors de son exécution, le conteneur Java de l'application JMeter consomme une bonne partie de la RAM, ce qui pourrait fausser vos résultats. JMeter est un outil purement Java, donc il peut fonctionner sous Windows et Linux. Pour mes tests, j'exécute JMeter sur Win08.<\/LI>Fiddler et Firebug. Je trouve que l'outil Fiddler<\/A> est utile pour dépanner les requêtes échouées et autres problèmes similaires. Il est aussi bon pour aider à construire les requêtes utilisées dans votre plan de test. Fiddler et Firebug (extension pour le navigateur Firefox) sont tous deux d'excellents outils légers pour tester et déboguer.<\/LI>L'environnement d'exécution Java (JRE) installé et une variable d'environnement pointant vers JAVA_HOME.<\/LI><\/UL>Par où commencer ?<\/STRONG>

Il n'y a pas vraiment d'installateur pour JMeter, tout ce dont vous avez besoin se trouve dans le dossier de l'application. La première chose à faire est d'ouvrir le dossier JMeterbin et jeter un œil au fichier JMeter.bat.  À la ligne 71, trouvez la ligne qui se lit comme suit :set HEAP=-Xms512m \u2013Xmx512m<\/EM>

Cette variable définit la quantité de mémoire dédiée au tas Java.

Je l'augmenterais à 1024, consacrant un gigaoctet complet à la JVM, comme ceci :set HEAP=-Xms1024m -Xmx1024m<\/EM>

Sinon, surtout lors des tests plus importants, vous risquez de dépasser le seuil du tas Java, ce qui peut provoquer l'échec de la JVM dédiée à JMeter.

Après avoir téléchargé JMeter, installé le JRE et défini la variable d'environnement JAVA_HOME pointant vers l'emplacement d'installation de Java, il est temps de lancer JMeter. Pour cela, ouvrez une invite de commande et naviguez jusqu'au répertoire BIN de JMeter (le même endroit où se trouve JMeter.bat). Appelez JMeter.bat depuis la ligne de commande et l'application JMeter s'ouvrira.<\/A>

Avec JMeter ouvert, il est temps de définir quelques valeurs par défaut. Pour cela, faites un clic droit sur l'icône Plan de Test (qui ressemble à un bécher) et ajoutez un élément HTTP Request Defaults.  (Ajouter>Élément Config>HTTP Request Defaults)<\/A>

Nous allons maintenant remplir certains paramètres sur la page HTTP Request Defaults.

Nom du serveur ou IP : c'est explicite. Insérez l'adresse IP ou le nom d'hôte de la machine qui exécute ArcGIS Server (ou le proxy qui pointe vers le serveur).  Je ne définis généralement pas les délais d'attente de connexion ou réponse ici dans JMeter. Le chemin sera celui vers votre point d'accès SOAP ou REST – vers l'opération que vous souhaitez effectuer (requête, exportation carte, etc.). Les paramètres envoyés avec la requête sont similaires à ceux définis si vous interrogez via le répertoire REST Services.

Je trouve utile d'utiliser l'outil Fiddler pour capturer les URL des requêtes envoyées soit via la page REST du service soit via votre application web afin d'aider à remplir ces paramètres.

Par exemple, vous pouvez émettre une requête basée sur un ensemble de coordonnées X\Y dans le but d'obtenir certains attributs pour une entité donnée. Dans ce cas, vous pouvez capturer une URL similaire à celle-ci dans Fiddler :

http:\/\/randall:6080\/arcgis\/rest\/services\/usa\/MapServer\/0\/query?where=\n&text=&objectIds=&time=&geometry=-119.78861600000%2C35.30318900030\n&geometryType=esriGeometryPoint&inSR=4269&spatialRel=esriSpatialRel\nIntersects&relationParam=&outFields=*&returnGeometry=true&maxAllowable\nOffset=&outSR=&returnIdsOnly=false&returnCountOnly=false&orderByFields\n=&groupByFieldsForStatistics=&outStatistics=&returnZ=false&returnM=false\n&f=pjson<\/PRE>
Dans cette URL, j'émets une requête vers la couche '0' dans un service appelé 'usa' servi depuis le port 6080 sur une machine appelée 'randall'.

Je n'utilise aucun opérateur SQL réel (la clause where), ni ne recherche un attribut texte spécifique (text). Je ne me soucie pas de l'ID objet ni du paramètre temps. Ce qui m'importe c'est la géométrie ; c'est là que mes valeurs XY sont spécifiées. En fait, les seuls éléments qui m'intéressent dans ce test sont la référence spatiale (4326), la relation spatiale (intersection), les champs retournés (* puisque je veux tous), et je soumets la géométrie comme un point. Enfin, pour ce test, je souhaite que le serveur réponde aux requêtes en format JSON.  Avec cela en tête, je peux tronquer un peu l'URL que je vais analyser afin de rendre la configuration du test JMeter plus gérable :http:\/localhost:6080\/ArcGIS\/rest\/services\/usa\/MapServer\/0\/query?&geometry\n=-149.54518800000%2C70.42196900010&geometryType=esriGeometryPoint&inSR=4269\n&spatialRel=esriSpatialRelIntersects&returnCountOnly=false&returnIdsOnly=\nfalse&returnGeometry=true&outFields=*&f=json<\/PRE>
Une fois ces valeurs par défaut rassemblées, je les insère dans mon projet JMeter :

<\/A>

Ensuite, je dois configurer des utilisateurs simulés. Bien que nous ayons défini les valeurs par défaut des requêtes, nous voulons tester avec plusieurs valeurs différentes – en d'autres termes, nous ne voulons pas que notre application prenne simplement la même requête encore et encore ; c'est trop simple. Il est préférable que nous puissions tester avec plusieurs échantillons différents.  Dans JMeter, cela se fait en créant des « groupes de threads ».

Faites un clic droit sur le plan de test et sélectionnez « Ajouter », puis « Threads (Utilisateurs) ». Dans mon cas, nous simulons une charge de 16 utilisateurs ; chaque groupe contiendra donc 2 threads. Je veux voir combien ma application peut supporter avant qu'elle ne plante ; je configure donc ce test en boucle infinie.<\/A>

Une fois les groupes Thread configurés, nous devons configurer les requêtes elles-mêmes qui contiennent les valeurs par défaut définies précédemment ainsi que les variables que nous voulons passer dans nos requêtes. Pour cela, faites un clic droit sur un groupe Thread ; choisissez « Ajouter », « Élément Config », puis « HTTP request defaults ». Cet écran devrait vous sembler familier ; il est exactement comme celui des valeurs par défaut créées initialement.

Dans ce cas précis, l'objectif du test est de voir quelle charge le serveur peut supporter si plusieurs centaines de milliers de requêtes query sont envoyées rassembler les attributs d'une entité en fonction des coordonnées XY transmises via la requête.

Ainsi, pour chaque requête envoyée par JMeter, le seul élément de la requête qui change d'une requête à l'autre sera la géométrie du point d'entrée. À cette fin, j'ai compilé un fichier .CSV, et configuré un élément CSV Data Set Configuration dans mon projet de test (Ajouter>Élément de configuration>Configuration du jeu de données CSV). Votre source de données n'a pas besoin d'être un CSV, vous pouvez utiliser une table de base de données si vous préférez – utilisez une connexion JDBC pour cela.<\/A>

Comme indiqué sur la figure ci-dessus, mon fichier CSV s'appelle xycord.csv (j'ai stocké le CSV dans le même dossier que mon plan de test – si le vôtre est stocké ailleurs, définissez le nom du fichier sur le chemin absolu où il se trouve.

Assurez-vous de définir correctement les noms des variables – s'il y a des espaces et des virgules dans votre fichier CSV ; assurez-vous que cet élément reflète ces espaces. La délimitation par virgule ici ne sépare que les noms des variables dans le CSV – le délimiteur réel utilisé dans le fichier CSV est décrit dans le paramètre « Delimiter ». Comme je laisse mon test s'exécuter jusqu'à ce que je l'arrête manuellement, je recycle les requêtes et ne m'arrête pas lorsque JMeter détecte la fin du fichier.

Pour mon test, j'ai répliqué chaque paramètre de requête HTTP pour chacun des utilisateurs que je simule dans les groupes de threads que j'ai configurés.

Il est maintenant temps de tester. Enregistrez le plan de test.

Dans JMeter, allez dans « Exécuter », puis « Démarrer ». Cliquez sur l'un des rapports.

Avec un peu de chance, vos requêtes s'exécuteront. Si le pourcentage d'erreur que vous obtenez est de 100 %, alors vous envoyez probablement des requêtes incorrectes.

Vous pouvez examiner les requêtes que vous envoyez au serveur en utilisant l'outil Fiddler :

Si Fiddler est installé sur la même machine que JMeter, alors dans la page principale des paramètres par défaut des requêtes HTTP, vous pouvez forcer le trafic à passer par le proxy Fiddler afin que les requêtes et les réponses ultérieures soient capturées. Par défaut, Fiddler écoute sur le port 8888, vous pouvez donc configurer JMeter comme suit :<\/A>

Lorsque vous relancez votre exécution JMeter, Fiddler capturera le trafic, ce qui vous permettra de voir ce que JMeter transmet afin que vous puissiez faire des ajustements selon vos besoins.Quelques conseils<\/STRONG>

Utilisez le moins possible d'écouteurs. Pour les tests plus petits, les compteurs graphiques sont excellents. Ces compteurs consomment beaucoup de mémoire cependant, et j'ai fait planter ma JVM avec des tests plus importants en utilisant ces compteurs. J'utilise simplement le Rapport Résumé – il contient les informations dont j'ai besoin.

Envisagez d'utiliser JMeter depuis une interface en ligne de commande une fois votre configuration mise en place. L'option Ligne de commande est peu gourmande en ressources.

C'est à peu près tout pour cet épisode. Je poursuivrai avec d'autres workflows de test dès que possible.Randall W. - Analyste Support Serveur<\/EM>



<\/BODY><\/HTML>

AndresCastillo

This is exactly the tool (also SoapUI) that we are using now to load test and debug some datastore crashes we are experiencing.

See related article:

https://community.esri.com/groups/technical-support/blog/2017/01/11/gauging-arcgis-gis-server-performance-with-integrated-windows-authentication 

Also, another tool that we use in case of a request failure:

https://community.esri.com/groups/technical-support/blog/2018/06/07/monitoring-web-service-requests-using-fiddler 

Also, Chrome Dev Tools>Network>export Har