Itinéraire Network Analyst
En termes simples, le solveur d'itinéraire Network Analyst est utilisé pour trouver le chemin le plus rapide pour aller d'un endroit à un autre. Ce trajet parcouru peut simplement impliquer un point de départ et un point d'arrivée, mais peut également s'arrêter à plusieurs endroits tout en demandant au solveur de générer des directions détaillées pour chaque itinéraire dans la solution.
Note : La fonctionnalité d'itinéraire est disponible avec une licence Network Analyst.
Test de charge d'un service d'itinéraire Network Analyst
Network Analyst est doté de nombreuses capacités et fonctionnalités pour la résolution d'itinéraires. De telles solutions peuvent être exécutées via ArcGIS Pro, mais sont souvent consommées via un service ArcGIS. Puisqu'il fournit une technologie de pointe pour les solutions d'itinéraires, il est logique de vouloir tester la charge de votre service solveur (itinéraire) localement exécuté afin d'en voir le potentiel de scalabilité.
Il existe plusieurs types d'analyse fournis par l'extension Network Analyst, cet article utilise les itinéraires car ils sont très faciles à manipuler... les seules entrées requises sont au moins deux points d'arrêt valides. Cette caractéristique en fait un bon choix pour démontrer comment générer des données et les utiliser dans un test de charge contre un service d'itinéraire.
Note : Le tutoriel dans cet article a utilisé ArcGIS Pro 2.9 avec des services Network Analyst fonctionnant dans un déploiement ArcGIS Enterprise 10.9.
Comment tester un service d'itinéraire Network Analyst ?
Données tutoriel Network Analyst ArcGIS Pro
La compréhension des processus dans cet article est plus efficace si les étapes peuvent être suivies en utilisant les mêmes données. Pour une telle tâche, l'équipe Network Analyst a mis à disposition un excellent ensemble de données.
Un tutoriel se trouve sur arcgis.com appelé Données tutoriel Network Analyst ArcGIS Pro. Compressé, il fait environ 132 Mo et consiste en des données Network Analyst pour plusieurs villes différentes : San Diego, Paris et San Francisco. Le système de coordonnées géographiques est : WGS 1984 (WKID : 4326). Les données sont accessibles publiquement.
Note : Les exemples dans cet article se concentreront sur l'ensemble de données de San Diego.
- Vue des données des rues de San Diego depuis ArcGIS Pro (avec fond topographique) :
- Les couches Streets, Walking_Pathways ou Network Dataset (NewSanDiego_ND) n'ont pas besoin d'être activées pour utiliser les capacités Network Analyst
- Dans l'exemple ci-dessus, elles sont activées pour servir de référence aux rues de San Diego
- Cet article ne couvrira pas les détails de la création, configuration ou publication d'un jeu de données réseau dans ArcGIS Enterprise. Pour des informations sur ces tâches, voir :
Note : Les exemples du solveur d'itinéraire dans cet article utilisent un service cartographique (avec la capacité d'analyse réseau) plutôt qu'un service de géotraitement. Le service cartographique utilise une exécution synchrone.
Génération des données de test
Cette opération de test nécessitera des points d'arrêt valides à utiliser dans le test JMeter.
Comme avec d'autres articles JMeter sur Community, nous avons besoin de bonnes données de test pour tirer le meilleur parti des résultats. Et comme auparavant, les Load Testing Tools facilitent grandement ce travail. Il existe même un outil spécifique pour créer des données d'itinéraires.
La version 1.3.0 ajoute quelques améliorations intéressantes à l'outil "Generate Data (Solve Route)".
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 placée à côté (bien qu'avec un nom de dossier différent) ou remplacer complètement la version précédente.
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 Data (Solve Route)" peut créer des données de test à partir du service (carte), d'une copie locale des données ou des données contenues dans une géodatabase entreprise. Pour cet exemple, toute donnée en WGS 1984 (WKID : 4326) avec une zone d'intérêt centrée autour de San Diego pourrait être utilisée.
Lancer l'outil Generate Data (Solve Route)
- Lancement de l'outil Generate Data (Solve Route) devrait présenter une interface similaire à la suivante :
- Dans sa forme la plus simple, seul le chemin du fichier csv, qui contiendra les points d'arrêt, doit être spécifié
- Cependant, bien que nous voulions générer des points aléatoires à utiliser comme arrêts, nous aimerions éviter de les créer dans les baies, lacs ou océan
- C'est là que le paramètre optionnel Constraining Polygon entre en jeu
- Ce champ d'entrée peut être utilisé pour référencer une couche de données afin de limiter spatialement où les points sont générés
- En réalité, nous allons ajuster toutes les valeurs par défaut
- Vue du polygone (en rose) délimitant la zone d'intérêt des données des rues de San Diego dans ArcGIS Pro :
Note : Ce polygone a été créé manuellement et n'est pas inclus avec l'ensemble de données San Diego
- Pour télécharger le shapefile SanDiegoPolygon utilisé dans cet article voir : SanDiegoPolygon.zip
Note : D'un point de vue test, le polygone ne doit pas inclure chaque segment de la couche rues
Entrées de l'outil Generate Data (Solve Route)
- Ajustez le nombre de tests à :
- Ajustez les arrêts par test à :
- Pointez le Constraining Polygon vers :
- Définissez la sortie vers un emplacement fichier où les résultats seront écrits :
- C:\Users\[nom_utilisateur]\Documents\ArcGIS\Projects\NetworkAnalystMap1\sandiegostops1.csv
- Cliquez sur Exécuter pour lancer l'outil
- L'examen du fichier CSV révélera les données générées des arrêts
< LI >Ces données seront utilisées directement dans le test Apache JMeter comme entrée
Afficher le fichier dans un éditeur de texte devrait montrer quelque chose de similaire à ce qui suit :
- Les fonctionnalités du route solver sont incroyablement vastes et pourraient accepter d'autres données spatiales, par exemple :
- Barrières, Barrières Polylignes et Barrières Polygones sont d'autres entrées qui pourraient être passées dans un paramètre de requête
- La génération de ces autres entrées pour les requêtes du route solver ne sera pas couverte dans cet Article
Visualiser spatialement les points générés
Les points générés qui sont utilisés pour les arrêts dans les requêtes peuvent être ajoutés au projet ArcGIS Pro pour visualiser spatialement leur emplacement.
- Depuis ArcGIS Pro, utilisez Catalog pour localiser et ouvrir la géodatabase fichier à l'intérieur du projet
- Localisez la classe d'entités random_pts
- Ajoutez la classe d'entités à la Carte Courante :
Le Plan de Test Route Solver
- Pour télécharger le Plan de Test Apache JMeter utilisé dans cet Article, voir : route_solver1.zip
- Ouvrir le Plan de Test dans Apache JMeter devrait ressembler à ce qui suit :
- Ajustez les Variables Définies par l'Utilisateur pour correspondre à votre environnement
Note : La version d'Apache JMeter utilisée pour cet Article était la 5.4.3 (cette version fournit des mises à jour critiques de sécurité pour Apache Log4j2). Il est fortement recommandé que tous les déploiements Apache JMeter fonctionnent sur la dernière version.
Requête HTTP
Le test route solve est simple et assez direct. Toute la logique du test se trouve dans un seul objet Requête HTTP JMeter. Suivant le style de test utilisé dans les Articles précédents, cet élément de requête est placé à l'intérieur d'un Contrôleur de Transaction.
Les paires clé/valeur pour la requête dans ce test JMeter sont basées sur deux facteurs :
- La fonctionnalité disponible dans le service Network Analyst publié (et les données sous-jacentes)
- Les valeurs dans ce test ont été prises directement des valeurs par défaut utilisées depuis le point de terminaison REST du service San Diego publié, par exemple :
- La version d'ArcGIS Enterprise (ArcGIS Server)
- Certaines versions ajoutent de nouvelles capacités
- Ce test est basé sur le service publié à partir du jeu de données San Diego et ArcGIS Enterprise 10.9
Différents jeux de données réseau peuvent avoir différentes options de paramètres de requête disponibles ou remplies, par défaut. Certains paramètres s'ils sont activés (comme returnDirections), indiqueront au solver de retourner plus d'informations. Cela demande en retour au service de faire plus de travail ce qui augmentera le temps de réponse de la requête.
Note : La vue de la Requête HTTP depuis la Table des Matières (côté gauche du Plan de Test) apparaîtra comme un mélange de variables JMeter et chaînes. C'est intentionnel. Ces valeurs seront remplies lors de l'exécution (dans l'objet View Results Tree et le fichier des résultats bruts).
Configuration du Thread Group
Le Plan de Test JMeter est configuré pour un test de charge de 20 minutes. Avec cet exemple utilisant deux arrêts pour chaque requête d'itinéraire, le solver devrait bien fonctionner et retourner un bon nombre d'échantillons (par ex. réponses du serveur) pour chaque étape.
- Différents environnements et données peuvent nécessiter un réglage alternatif pour atteindre les résultats souhaités, ajustez les paramètres des threads du test selon les besoins
Validation du Plan de Test
Comme bonne pratique, il est toujours conseillé de valider les résultats retournés dans l'interface graphique JMeter avant d'exécuter le test de charge réel en ligne de commande.
- Utilisez l'écouteur View Results Tree pour aider à la validation
- Le Plan de Test pour cet Article inclut un écouteur View Results Tree mais il est désactivé
- Activez-le pour voir les résultats lorsque le test est lancé depuis l'interface graphique
- Depuis l'interface graphique, démarrez le test
- Laissez tourner le test pendant environ 20 secondes
Transactions
- Sélectionnez une des Transactions "Route"
- La section View Results Tree devrait ressembler à ce qui suit :
- Dans cet exemple, toutes les transactions se sont terminées avec succès
- Parfois, en arrêtant la lecture, les dernières Transactions dans View Results Tree peuvent échouer car elles ont été arrêtées "en cours de requête" ; cela peut être ignoré sans risque
Requêtes
- Détendez une des Transactions "Route"
- Sélectionnez la requête HTTPS à l'intérieur
- Les résultats devraient ressembler à ce qui suit :
- Dans cet exemple, la requête sélectionnée s'est terminée avec succès (indiqué par la coche verte)
- Le succès de la Transaction parente indiquait déjà ce statut
- Depuis l'onglet résultat Sampler, jetez un coup d'œil rapide au champ Taille en octets
- Dans cet exemple, la taille de la requête était d'environ 15KB ce qui signifie généralement que des bonnes données géométriques ont été retournées ; en d'autres termes, les réponses n'étaient pas "vides" et c'est une preuve supplémentaire que cela a réussi
- Examinez l'URL de la requête
- Comme mentionné précédemment, cette valeur URL devient remplie au moment de l'exécution
- Cliquez sur l'onglet Données réponse et sous-onglet Corps réponse
- Cela montre une vue textuelle des données retournées par la requête :
Note : Les géométries d'itinéraire retournées sont couramment rendues dans les applications JavaScript basées sur navigateur web. Bien qu'Apache JMeter soit un client (de test), il ne rend pas spatialement ces réponses de géométrie du serveur de cette manière.<\/STRONG><\/FONT><\/P>Exécution du Test<\/H1>Le test de charge doit être exécuté de la même manière qu'un plan de test JMeter typique.<\/P>Voir le script runMe.bat inclus avec le projet route_solver1.zip pour un exemple sur la façon d'exécuter un test comme recommandé par l'équipe Apache JMeter. <\/P>Le script runMe.bat contient une variable jmeterbin<\/EM> <\/SPAN>qui devra être définie à la valeur appropriée pour votre environnement<\/LI>Si le service d'itinéraire Network Analyst a été publié en tant que dédié, <\/FONT>ajustez les instances minimales et maximales en conséquence avant d'exécuter le test de charge<\/FONT>
Pour plus d'informations, voir : Configurer les paramètres d'instance de service<\/A> <\/STRONG><\/FONT><\/LI><\/UL><\/LI>Le service d'itinéraire publié utilisé dans cet article était dédié avec un maximum d'instances fixé à 4- Le composant ArcGIS Server fonctionnait sur un système avec 4 cœurs CPU<\/LI><\/UL><\/LI><\/UL>
Note : Il est toujours recommandé<\/U><\/EM> 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 pourraient également avoir besoin d'utiliser votre site ArcGIS Enterprise sur site. De plus, cela aide à prévenir le bruit système<\/EM> provenant d'autres activités et utilisations qui pourraient "polluer" les résultats du test.<\/STRONG><\/FONT><\/P>Note : Pour plusieurs raisons, il est fortement conseillé de ne jamais effectuer de test de charge sur ArcGIS Online<\/EM><\/U>.<\/STRONG><\/FONT><\/P>
Rapport JMeter<\/H1>Courbe de Débit<\/H2>Le rapport JMeter auto-généré peut fournir des informations sur le débit du service d'itinéraire sous chargeÉtant donné que chaque transaction d'itinéraire contenait une requête, les deux métriques (requête et transaction) montraient pratiquement la même valeur ; cela est attendu compte tenu de la conception du test<\/LI><\/UL><\/LI>Dans ce cas, le débit maximal pour les résolutions d'itinéraires à deux arrêts était d'environ 15 transactions par secondeCompte tenu de l'environnement testé, cela équivaut à environ 54 000 résolutions d'itinéraires par heure <\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Courbes de Performance<\/H2>Le rapport JMeter auto-généré peut également fournir des informations sur la performance du service d'itinéraire sous chargeÉtant donné que chaque transaction d'itinéraire contenait une requête, les deux métriques (requête et transaction) montraient pratiquement la même valeur ; cela est attendu compte tenu de la conception du test<\/LI><\/UL><\/LI>La performance des requêtes d'itinéraire était bonne et inférieure à 1 seconde tout au long du test de chargeLà où le débit a atteint son pic à 15 transactions par seconde est l'endroit où le temps de réponse a été mesuréÀ ce point du test, le temps moyen de réponse était d'environ 333 ms ou 0,33 secondes<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Il peut également être utile de voir les temps de réponse tracés par rapport à la charge progressive (threads configurés)Les graphiques précédents montraient des valeurs en fonction du temps<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Réflexions Finales<\/H1>Le plan de test Apache JMeter dans cet article représente une approche programmatique pour appliquer une charge à un service d'itinéraire Network Analyst. L'un des points forts de ce test est qu'il est facile à configurer et à maintenir.<\/P>Le rapport JMeter auto-généré fournit des graphiques et des résumés qui peuvent être utilisés pour analyser rapidement la performance et l'évolutivité du service d'itinéraire.<\/P>Pour télécharger le plan de test Apache JMeter utilisé dans cet article, voir : route_solver1.zip<\/><\/>\/<\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\
