Pourquoi tester un service de couche d'entités hébergé ?
Les articles communautaires précédents sur les tests de performance avec Apache JMeter se concentraient sur l'exercice des services de carte via la fonction d'exportation. Cependant, les couches hébergées (feature) sont également une capacité populaire d'ArcGIS Enterprise et sont largement utilisées dans les déploiements. De plus, l'interrogation de ces couches est basée sur une conception en grille "répétée" qui peut aider à fournir un degré plus élevé d'évolutivité par rapport à d'autres technologies de visualisation. Ajoutez à cela le rendu côté client des données retournées et c'est gagnant-gagnant.
Étant donné que les services d'entités hébergés sont une technologie de service éprouvée et favorite, il est logique de vouloir tester les requêtes d'entités sous charge pour observer leur évolutivité de première main.
Défis des tests des services de couche d'entités hébergés
Comparé au test de la fonction d'exportation de carte, tester les requêtes du service de couche d'entités hébergé est un défi car les requêtes sont plus complexes à réaliser programmatiquement. Un "pan" ou un "zoom" de navigation dans le navigateur web produit plusieurs requêtes différentes, chacune avec sa propre géométrie. Pour répéter ce comportement, le test de charge construit n'aura pas qu'une seule requête à émettre mais plusieurs et en nombre variable. Ajoutez à cela le fait que chaque requête dans la transaction aura une géométrie unique et un maxAllowableOffset changeant (selon l'échelle de la carte) et il y a beaucoup d'éléments mobiles à suivre.
Comment tester un service d'entités hébergé ?
Le jeu de données USGS Motor Vehicle Use Roads
La compréhension du processus dans cet article est plus efficace si les étapes peuvent être reproduites. Mais cette répétabilité nécessite l'accès au même ensemble de données. La taille spatiale de la source de données doit également être suffisamment grande pour générer des données de test correctes mais pas trop grande pour être encombrante à télécharger.
Entrez dans le jeu de données Motor Vehicle Use Map: Roads sur hub.arcgis.com. Les 179K enregistrements polyline des données USGS Roads en WGS 1984 Web Mercator (Auxiliary_Sphere), équivalent à environ 200 Mo compressés. Il est fourni sous licence Creative Commons (CC0).
- Vue des données Roads depuis ArcGIS Pro :
- Vue à grande échelle avec étiquetage activé :
Ces données seront publiées depuis ArcGIS Pro vers un service d'entités hébergé dans ArcGIS Enterprise ou chargées directement via Portal for ArcGIS.
Génération des données de test
Ce test nécessitera de bonnes données de test à utiliser dans le test JMeter.
Pour relever cette tâche, il est fortement recommandé d'utiliser les très excellents Load Testing Tools.
La version 1.2.2 ajoute de nouvelles capacités comme l'outil "Generate Query Extents" qui sera d'une grande aide pour générer des données de test pour le service d'entités.
Ces données utilisent la conception basée sur une grille, ce que nous voulons. Avec l'approche basée sur la grille, des enveloppes pour la zone désirée sont créées en arrière-plan. Ensuite, ces enveloppes sont converties aux étendues de requête appropriées 512x512. Le nombre des requêtes (pour chaque enveloppe initiale) variera selon où elle se trouve sur la grille... cela imite le comportement du service dans un navigateur web.
Rendre les outils disponibles depuis ArcGIS Pro
Une fois que le projet load-testing-tools a été téléchargé sur votre machine, placez le dossier décompressé dans un répertoire accessible ou rendu accessible par ArcGIS Pro. Si vous avez déjà une version précédente des Load Testing Tools installée, cette version mise à jour peut être installée parallèlement (bien qu'avec un nom de dossier différent) ou remplacer complètement le dossier existant.
Par exemple :
- Placez le dossier load-testing-tools dans C:\Users\[nom_utilisateur]\Documents\ArcGIS
- Utilisez la connexion Ajouter un dossier depuis Catalog dans ArcGIS Pro pour lister le contenu de ce répertoire :
L'outil "Generate Query Extents" peut fonctionner à partir du service d'entités hébergé, d'une copie locale des données ou des données contenues dans une géodatabase entreprise.
Note : l'outil doit générer des étendues de requête à partir de n'importe quelles données mais il nécessite que le système de coordonnées projetées soit WGS 1984 Web Mercator Auxiliary_Sphere (WKID : 3857).
Sélectionner une zone d'intérêt
Sélectionnez une zone d'intérêt sur la carte pour générer les données de test. Dans cet exemple, les données Roads sont visualisées depuis le nord-ouest des États-Unis (près des frontières des états Idaho et Montana). L'échelle sélectionnée est 1:1 000 000.
Lancer l'outil Generate Query Extents
- Lancer l'outil Generate Query Extents devrait présenter des entrées similaires aux suivantes :
Ajuster les entrées pour l'outil Generate Query Extents
Les entrées par défaut ont été ajustées pour refléter ce qui suit :
- Plusieurs niveaux d'échelle plus petits et plus grands ont été supprimés
- Les niveaux d'échelle restants sont 12, 13 et 14 qui correspondent aux échelles cartographiques 144448, 72224 et 36112 respectivement
- Le nombre d'enregistrements pour ces échelles a été augmenté
- Le niveau d'échelle 14 peut être omis selon la version des Load Testing Tools (si absent, veuillez ajouter ce niveau manuellement)
- L'emplacement du fichier de sortie qui devrait être quelque chose comme :
- C:\Users\username\Documents\ArcGIS\Projects\Catalog2\query_extents.csv
- Cliquez sur Exécuter pour lancer l'outil
Note : La durée nécessaire pour générer les données de test dépend de plusieurs facteurs tels que le nombre différent de niveaux d'échelle, le nombre d'enregistrements (par niveau) et l'échelle actuelle du projet.
Note : Générer des données de test avec d'autres jeux peut nécessiter l'utilisation de différents niveaux d'échelle selon le niveau de détail et la densité des entités.
Validation des données générées
Il est bon de vérifier visuellement les données générées. Cela permet au testeur de savoir ce que le test sous charge va spatialement demander au service d'entités.
Une fois que l'outil a terminé avec succès il générera 3 ensembles principaux de données qui présentent un intérêt :<\/P>
- Classes d'entités de boîte englobante
- Contient des zones d'intérêt générées aléatoirement<\/LI>
- Une classe d'entités pour chaque niveau d'échelle demandé<\/LI><\/UL><\/LI>
- Classes d'entités d'étendue de requête
- Contient une grille de tuiles (512x512) sur laquelle chaque requête de fonctionnalité sera basée<\/LI>
- Une classe d'entités pour chaque niveau d'échelle demandé<\/LI><\/UL><\/LI>
- Fichiers CSV d'étendue de requête
- Contient les données de test générées<\/LI>
- Chaque ligne est composée des composants dynamiques d'une requête de service de fonctionnalités<\/LI>
- Un fichier pour chaque niveau d'échelle demandé<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Depuis le panneau Catalogue, chargez la classe d'entités bbox_36112 sur la carte actuelle dans ArcGIS ProCette sortie est très similaire aux données de l'outil Generate Bounding Boxes<\/LI><\/UL><\/LI>Dans cet exemple, les boîtes générées aléatoirement sont en roseCes zones représentent la résolution d'écran d'un utilisateur demandant des données au service de fonctionnalités<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Maintenant, depuis le panneau Catalogue, chargez la classe d'entités query_extents_36112 sur la carte actuelle mais derrière (en dessous) des données bbox_36112<\/LI>Dans cet exemple, les boîtes de la grille de tuiles de requête sont en vertCes tuiles correspondent à une zone sur la carte pour laquelle les bboxes demandent des données<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Zoomer sur la carte peut permettre une meilleure compréhension de la relation entre ces deux ensembles de données<\/LI>Comme on le voit sur la carte ci-dessous, certaines bboxes sont légèrement décalées les unes par rapport aux autres mais partagent toujours une tuile de requête commune provenant de la grille en dessous<\/LI>Les coordonnées de ces tuiles de requête (par exemple à partir de la classe d'entités query_extent) sont ce qui sera intégré dans les fichiers CSV et finalement dans le test de charge JMeter<\/LI><\/UL>
<\/span><\/P>Regarder de plus près les bboxes révèle des détails sur leur composition respective de requêtePar exemple, certaines bboxes peuvent nécessiter 12 tuiles "sous-jacentes" pour être satisfaites, d'autres 15 ou 20<\/LI>Comme on le voit sur la carte ci-dessous, la bbox mise en évidence en noir nécessite 12 tuiles spécifiques colorées en rouge<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P> Note : La conception de la grille de tuiles du service de fonctionnalités est l'un de ses points forts clés car elle se prête à la répétabilité. Cette répétabilité peut être exploitée avec la mise en cache dans un déploiement pour améliorer l'évolutivité. Cela n'est pas possible avec export map.<\/STRONG><\/FONT><\/P>L'examen des fichiers CSV générés révélera les résultats finaux de cette transformation<\/LI>La visualisation du fichier query_extents_36112.csv dans un éditeur de texte devrait montrer quelque chose de similaire à ce qui suitSelon la version des Load Test Tools, les fichiers CSV peuvent être triés par la colonne operationid<\/LI><\/UL><\/LI><\/UL>
- Selon la version des Load Testing Tools, la ligne peut ou non être groupée par la colonne operationid<\SPAN></ LI >< LI > La compréhension du operationid, dans ce cas, est un concept important pour les tests car chaque opération représente une action de navigation (par exemple un panoramique ou un zoom)<\SPAN></ LI >< LI > Du point de vue de JMeter, une opération est équivalente à une transaction <\SPAN></ LI >< UL class = "lia-list-style-type-circle"> < LI > Toutes les lignes avec un operationid correspondant deviendront des géométries de requêtes du service feature sous le même contrôleur transaction <\ LI > <\ UL > <\ LI > <\ UL > Le plan de test Hosted Feature Service Query <\ H1 > < UL > < LI > Pour télécharger le plan de test Apache JMeter utilisé dans cet article, voir : <\ SPAN > < STRONG >< A href = "https://community.esri.com/ccqpr47374/attachments/ccqpr47374/implementing-arcgis-blog/280.47/8/roads_hfs1.zip " target = "_self"> roads_hfs1.zip <\ A > <\ STRONG > <\ 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 class = "lia-list-style-type-square"> < LI > Les 3 fichiers CSV générés par l'outil sont référencés via les variables JMeter DataFile_A, DataFile_B et DataFile_C uniquement par le nom du fichier (le chemin du système de fichiers n'est pas inclus ici) <\ LI > <\ UL > <\ LI > <\ UL > <\ LI > <\ UL > < P >< span class = "lia-inline-image-display-wrapper lia-image-align-center " image-alt = "jmeter_hfs_testplan.png " style = "width: 999px; " >< img src = "https://us.v-cdn.net/6038851/uploads/images/26129i672759E7E8A0672C/jmeter_hfs_testplan.png " role = "button " title = "jmeter_hfs_testplan.png " alt = "jmeter_hfs_testplan.png " / >< / span >< / P >< H2 id = "toc-hId-1850417758"> Composants du plan de test < / H2 >< H3 id = "toc-hId-172046014"> Logique du lecteur de données < / H3 >< P > Le test roads_hfs est un peu différent des autres exemples de tests Apache JMeter utilisés dans les articles précédents. La principale différence est que bien qu'il s'agisse toujours d'un test piloté par les données (par exemple, des fichiers CSV sont utilisés comme entrée des requêtes), il n'utilise pas l'objet élément Config « CSV Data Set Config » typique pour lire les données. Au lieu de cela, cette logique est effectuée via des échantillonneurs JSR223 qui exécutent du code Groovy. La raison pour laquelle Groovy est utilisé est liée à la nature d'interaction avec un service feature mentionné plus tôt. Rappelez-vous que certaines transactions auront 12 requêtes et d'autres peuvent en avoir 15 ou 20 (selon l'endroit où se situe globalement la zone d'intérêt sur la grille des tuiles). Cette différence dans le nombre de requêtes nécessite que le test utilise un mécanisme plus flexible pour lire et utiliser les données des fichiers CSV puisque cela ne sera pas constant.< / P >< UL >< LI > Il y a un échantillonneur JSR223 pour chaque fichier CSV (par exemple chaque échelle cartographique) < UL class = "lia-list-style-type-circle"> < LI > Tous les échantillonneurs JSR223 pour la lecture des données sont placés dans un contrôleur Once Only afin de minimiser la surcharge < UL class = "lia-list-style-type-square"> < LI > La lecture du fichier CSV ne sera effectuée qu'une seule fois, au début de chaque thread du test < / LI > < / UL > < / LI > < / UL > < / LI >< LI > Ci-dessous se trouve « JSR223 Sample A1 » qui lira le fichier query_extents_72224.csv < UL class = "lia-list-style-type-circle"> < LI > Une expérience en codage Groovy n'est pas nécessaire pour exécuter ce test, en fait ces échantillonneurs JSR223 n'ont pas besoin d'être modifiés pour exécuter le test, mais il est utile de comprendre quelle logique est responsable de lire les données CSV < / LI > < / UL > < / LI >< / UL >< P >< span class = "lia-inline-image-display-wrapper lia-image-align-center " image-alt = "jmeter_hfs_datareader_logic.png " style = "width: 999px; " >< img src = "https://us.v-cdn.net/6038851/uploads/images/26130i8EEB99EC5258796F/jmeter_hfs_datareader_logic.png " role = "button " title = "jmeter_hfs_datareader_logic.png " alt = "jmeter_hfs_datareader_logic.png " / >< / span >< / P >< H3 id = "toc-hId--1635408449">Logique de sélection Operation IDUne fois que les données CSV ont été lues, le test devra sélectionner un operation id pour chaque échelle à chaque itération du test. Pour cela, un second ensemble d’échantillonneurs JSR223 a été utilisé pour choisir parmi chaque liste d’opérations.
Il y a un échantillonneur JSR223 pour chaque échelle cartographique qui sélectionne aléatoirement un operation id
Tous les échantillonneurs JSR223 générant cet operation id sont placés dans un contrôleur Transaction appelé Operation Generator
Ceci est exécuté à chaque itération du thread du test
- Ces échantillonneurs JSR223 n'ont pas besoin d'être modifiés pour exécuter le test
Note : Les JSR223 Samplers utilisant Groovy sont généralement exécutés rapidement et ajoutent très peu de surcharge au test
Boucle d'opération et peuplement des paramètres
Avec un id d'opération choisi, l'attention se porte sur la logique de boucle où le test recherchera le nombre de requêtes de services de fonctionnalités qui composent la transaction. À partir de là, il utilisera un troisième ensemble de JSR223 Samplers pour peupler les paramètres des requêtes associés à l'id d'opération précédemment sélectionné à chaque itération dans la boucle.
- Il y a un JSR223 Sampler pour chaque échelle de carte qui peuple les variables JMeter associées en fonction de l'id d'opération et de la valeur d'itération
- Ces éléments deviennent alors des paires clé/valeur qui sont récupérées par la Requête HTTP
- Les valeurs d'itération sont suivies par un élément de configuration Compteur
- Ces JSR223 Samplers n'ont pas besoin d'être modifiés pour exécuter le test
- Chaque Contrôleur de boucle, Compteur, JSR223 Sampler et objet Requête HTTP sont tous placés à l'intérieur d'un Contrôleur de transaction correspondant pour séparer logiquement les éléments pour chaque échelle de carte
Requête HTTP
Essentiellement, toute la logique du test ci-dessus existe uniquement pour ce composant du test. Ici, l'objet Requête HTTP JMeter peut lire les variables JMeter pour des paramètres clé/valeur spécifiques qui ont été peuplés par le JSR223 Sampler immédiatement avant lui.
Étant donné que cette approche est hautement programmatique, il n'y a qu'une seule Requête HTTP par échelle de carte ! Une telle conception favorise la maintenabilité.
Note : Cette approche de test fonctionnerait également pour les services de couches de fonctionnalités traditionnels non hébergés. Cependant, ces services de fonctionnalités n'ont pas les mêmes optimisations des paramètres de requête que les services hébergés comme maxAllowableOffset et quantizationParameters. Ces options devraient simplement être supprimées de la Requête HTTP.
La configuration du groupe de threads
Le plan de test JMeter est actuellement configuré pour un test relativement court de 10 minutes. En général, les services de fonctionnalités hébergés fonctionnent bien, donc beaucoup de débit aura lieu à chaque étape (1 minute par étape) ainsi que sur l'ensemble du test.
- Différents environnements et données peuvent nécessiter un réglage alternatif pour atteindre les résultats souhaités, ajustez selon les besoins
Validation du plan de test
Comme bonne pratique, il est toujours conseillé de valider les résultats obtenus avant d'exécuter le test de charge réel.
- Utilisez l'écouteur View Results Tree pour aider à la validation
- Le plan de test inclut un écouteur View Results Tree mais il est désactivé par défaut
- Activez-le pour voir les résultats
- Depuis l'interface graphique, démarrez le test
Transactions
- Sélectionnez une des transactions "HFS"
- Les résultats devraient ressembler à ce qui suit :
- Dans cet exemple, les transactions listées ci-dessus : HFS (mapscale : 72224), HFS (mapscale : 36112), et HFS (mapscale : 144448) ont toutes été complétées avec succès
- Le résultat du Sampler liste quelques détails supplémentaires
- Bien que chaque Transaction ait envoyé une requête HTTP par étendue de requête fonctionnelle, le test JMeter compte le Sampler comme faisant partie de l'opération
- Les JSR223 Samplers ajoutent très peu de surcharge à la Transaction bien qu'ils doublent le nombre d'échantillons, c'est juste un détail à connaître
- Jetez un coup d'œil rapide à la taille en octets
- Dans cet exemple, la taille de la Transaction était presque 65KB ce qui suggère que des données ont été retournées et que les réponses n'étaient pas "vides"
Requêtes
- Détendez une des transactions "HFS"
- Sélectionnez une des requêtes https
- Les résultats devraient ressembler à ce qui suit :
- Dans cet exemple, la requête select s'est terminée avec succès
- Jetez un coup d'œil rapide à la taille en octets
- Dans cet exemple, la taille de la requête était d'environ 5KB ce qui suggère que des données ont été retournées et que les réponses n'étaient pas "vides" (par ex. 1500 octets)
- Le ContentType est également important
- Selon les paramètres dans le plan de test, le format demandé est pbf qui retourne application/x-protobuf
- Demander des protocol buffers est une bonne pratique car cela optimise la charge utile
- Le format résultant est binaire et ne peut pas être facilement visualisé sans aide supplémentaire qui n'est pas couverte dans cet article
Note : Les services fonctionnels (y compris les services fonctionnels hébergés) sont rendus côté client (et non côté serveur comme export map). Bien qu'Apache JMeter soit un client (de test), il ne rend pas les réponses du serveur via JavaScript comme un navigateur web.
Exécution du test
Le test de charge doit être exécuté de la même manière qu'un plan de test JMeter typique.
Voir le script runMe.bat inclus avec le projet roads_hfs1.zip pour un exemple sur comment exécuter un test comme recommandé par l'équipe Apache JMeter.
- Le script runMe.bat contient une variable jmeterbin qui devra être définie à la valeur appropriée pour votre environnement
Note : Il est toujours recommandé de coordonner l'heure et la durée du début du test de charge avec le personnel approprié. Cela garantit un impact minimal aux utilisateurs et autres collègues qui peuvent également avoir besoin d'utiliser le site ArcGIS Enterprise. De plus, cela aide à prévenir le brouillage système provenant d'autres activités et utilisations pouvant "polluer" les résultats du test.
Rapport JMeter
Courbes de débit
- Le rapport JMeter auto-généré peut fournir un aperçu du débit des transactions HFS sous charge
- Les transactions non-HFS ont été filtrées manuellement
- Dans ce cas, le débit maximal pour les opérations HFS était d'environ 16,5 transactions/seconde
- Puisqu'il y avait 3 transactions HFS, cela équivaut à presque 50 transactions/seconde (ou 178 200 transactions/heure)
Note : Chacune des transactions HFS aura naturellement un débit similaire car leur exécution respective dans le test a été pondérée de manière identique
dans ce cas, les transactions HFS pour toutes les échelles étaient inférieures à une seconde (moins de 1 seconde)- Même vers la fin du test, sous la charge la plus lourde, le temps de réponse moyen était inférieur à 225 ms ou 0,225 secondes
Réflexions finales
Il existe d'autres façons de tester les requêtes d'un service de couche de fonctionnalités hébergé, comme par exemple via le trafic capturé depuis un navigateur web lors de l'interaction avec le point de terminaison ou l'application. Cela produirait une liste des URL du service qui pourrait être traduite en un test. Cependant, une approche programmatique telle que celle décrite dans cet Article offre une stratégie pour tester une vaste zone spatiale du service couvrant beaucoup plus d'étendues que ce qui peut être pratiquement fait avec l'approche du trafic capturé.
L'approche programmatique est également plus facile à maintenir car la taille du Plan de Test est beaucoup plus petite. Pour mettre cela en perspective, le test JMeter contenu dans cet Article ne contenait que 3 requêtes HTTP (une pour chaque échelle de carte).
Apache JMeter publié sous la Apache License 2.0. Apache, Apache JMeter, JMeter, la plume Apache et le logo Apache JMeter sont des marques déposées de la Apache Software Foundation.
