Choisir une capacité d'ArcGIS Enterprise pour établir une référence
En tant que système logiciel fondamental pour les SIG, ArcGIS Enterprise exécute de nombreuses tâches telles que la cartographie et la visualisation, l'analyse. Parmi cette large gamme de capacités et de fonctions, il n'existe pas de test unique pouvant représenter toutes ses capacités.
Cependant, si une fonction devait être utilisée comme référence pour tester un déploiement ArcGIS Enterprise, un argument solide peut être avancé en faveur de la fonction d'exportation du service de carte. L'exportation de carte peut être appelée facilement et de manière programmatique dans un plan de test Apache JMeter en variant les étendues spatiales des requêtes à partir de fichiers de données CSV à plusieurs échelles de carte. Cela se traduit par une seule requête pour chaque transaction d'échelle de carte, ce qui aide à garder le test simple et facile à maintenir. Associé au fait que la fonction d'exportation est disponible depuis la version 9.3, cela constitue une opération éprouvée et fiable pour établir une référence.
Qu'est-ce qu'une référence d'un service de carte ?
Les testeurs et administrateurs SIG sont souvent chargés de comprendre les différences de débit entre deux systèmes ou le même système après une modification quelconque de l'environnement. Dans de tels scénarios, une référence est le processus consistant à réaliser un test de charge servant de norme à laquelle plusieurs éléments peuvent être comparés entre eux.
En ce qui concerne les SIG, ce test de charge serait un plan de test Apache JMeter exécutant un test de charge progressive contre un service de carte ArcGIS Enterprise afin de comprendre le taux maximal de débit (transactions/sec ou requêtes/sec) pouvant être atteint par le déploiement dans un état ou une configuration particulière. Ce taux est également connu sous le nom de débit maximal. À ce débit maximal, il est également essentiel de mesurer la performance (temps de réponse des transactions ou des requêtes).
Jeu de données de référence
Tout jeu de données peut être utilisé pour une référence tant qu'il reste constant, c'est-à-dire sans modifications telles que des ajouts, mises à jour, suppressions ou versions des classes d'entités. Cette constance aide à créer une "norme" fiable puisqu'il s'agit d'une cible fixe. Les données du test peuvent être privées (par exemple propriétaires) ou issues du domaine public.
Qu'est-ce que les données du domaine public ?
De manière générale, les données du domaine public sont tous les jeux de données raster ou vectoriels gratuits à télécharger et à utiliser. Il existe de nombreux jeux de données du domaine public (et potentiellement différentes licences qui les définissent). Les données utilisées dans cet article sont réalisées avec Natural Earth et fournies sous licence Creative Commons (CC0).
Pourquoi utiliser des données du domaine public ?
L'une des caractéristiques qui font une bonne référence est la construction d'un test permettant aux autres de répéter le même test que vous avez effectué. Les données du domaine public sont un bon choix à cet égard car elles favorisent une norme de test et une mesure fiable pour la performance et l'évolutivité.
SampleWorldCities vs Natural Earth
Alors que l'inclusion par ArcGIS Server du jeu SampleWorldCities via son installation aide à rendre ce jeu omniprésent et adapté aux exemples et démonstrations, sa taille extrêmement petite ne le rend pas idéal pour établir une référence d'un service de carte.
Les jeux Natural Earth, en revanche, offrent un niveau correct de détail cartographique (à plus petites échelles) couvrant le monde entier. De plus, cela peut être réalisé avec une empreinte disque facilement gérable, ce qui facilite son partage, téléchargement et utilisation.
Le jeu Natural Earth pour la référence
Architecture du déploiement
L'architecture est un détail important d'une référence. Les composants suivants sont tous importants dans l'architecture d'une référence car ils ont un impact sur le test :
- Un Web Adaptor existe-t-il ?
- L'authentification a-t-elle été impliquée ou le service a-t-il été rendu disponible à tous ?
- Authentification Portal for ArcGIS
- Authentification par jeton ArcGIS Server
- Disponible pour tous
- Combien de machines ont participé au site ArcGIS ?
- Détails du processeur
- Modèle et architecture du processeur
- Nombre de cœurs CPU pour chaque serveur (y compris la station client effectuant les tests)
- Physique, virtuel ou cloud
- Détails sur la mémoire physique
- Quantité totale de mémoire système
- Vitesse réseau
- Version d'ArcGIS Enterprise
- Version du système d'exploitation
Note : Il est recommandé de noter les détails architecturaux du déploiement. Enregistrer ces informations avec les résultats du test peut aider à donner un contexte approprié et du sens à l'analyse ou aux conclusions.
Les résultats listés pour ce test de référence ont été réalisés sur l'architecture environnementale suivante :
- ArcGIS Server (10.9 Final)
- Dell PowerEdge R640
- Windows Server 2019
- Réseau 10G
- ArcGIS Web Adaptor (10.9 Final)
- Dell PowerEdge R440
- Windows Server 2019
- Réseau 10G
- Client Test
- Apache JMeter 5.4.1
- Dell PowerEdge R640
- SPECint_rate_base2006
- Système Windows Server 2019
- Réseau 10G
si le déploiement comprend plusieurs serveurs qui composent le Site ArcGIS Enterprise. Dans les deux cas, à distance ou local, l'emplacement de la source de données est également un détail important de l'environnement de test qui doit être noté.<\/SPAN><\/P>Note : Il est recommandé de noter l'emplacement de la source de données. Enregistrer cette information avec les résultats du test peut aider à donner un contexte et une signification appropriés à l'analyse ou aux conclusions.<\/STRONG><\/FONT><\/P>Type de service et nombre d'instances<\/FONT><\/H2>Pour les services cartographiques ArcGIS les plus utilisés dans un Site, il est recommandé de publier la ressource en tant qu'instance Dédiée plutôt que Partagée. Bien que les deux types puissent évoluer pour utiliser pleinement le matériel disponible, une instance de service Dédiée dispose de ressources en coulisses qui lui sont consacrées, ce qui en fait un choix idéal pour un test de référence.<\/FONT><\/P>Pour des performances prévisibles, il est recommandé de définir le nombre minimum et maximum d'instances pour le type d'instance Dédiée égal au nombre de cœurs CPU de la machine ArcGIS Server.<\/FONT><\/P>Note : Il est recommandé de noter le type de service et le nombre d'instances. Enregistrer cette information avec les résultats du test peut aider à donner un contexte et une signification appropriés à l'analyse ou aux conclusions.<\/STRONG><\/FONT><\/P>Les options de requête dans un test de référence ont-elles de l'importance ?<\/H2>Absolument ! Utiliser un jeu de données commun et la fonction d'exportation de carte ne suffit pas à établir un benchmark fiable. L'opération d'exportation est extrêmement polyvalente mais grâce à cette flexibilité, une image peut être générée via une variété d'options d'entrée différentes.<\/P>Un test de charge qui envoie des requêtes au service cartographique de manière constante est important pour établir un benchmark fiable. Le test peut-il demander un format d'image BMP au lieu d'un PNG ou demander que les données soient dans une référence spatiale différente du 4326 par défaut ? Oui, mais changer ces options peut impacter les performances et la scalabilité du test, il est donc recommandé de laisser ces paramètres du Plan de Test tels quels.<\/P>Le plan de test Benchmark du service cartographique <\/H1>Pour télécharger le Plan de Test Apache JMeter utilisé dans cet article, voir : <\/SPAN>naturalearth1.zip<\/A> <\/STRONG>- Ce Plan de Test est largement basé sur le projet SampleWorldCities issu d'
un article précédent<\/A><\/LI><\/UL><\/LI><\/UL>- Télécharger et ouvrir le Plan de Test dans Apache JMeter devrait ressembler à ce qui suit :
La configuration du groupe de threads<\/H2>Le groupe de threads définit les caractéristiques de charge progressive du test et joue un rôle important. Pour une exportation de carte, le nombre maximum de threads pour le test a une relation étroite avec le nombre maximum de cœurs CPU du serveur ArcGIS (et, de même, le nombre maximum d'instances du service). Configurer les threads du test pour dépasser le nombre de cœurs aide à garantir qu'une pression suffisante est appliquée pour utiliser pleinement les ressources CPU du serveur. À partir de là, un débit maximal devrait être observé, ce qui est un objectif principal d'un test benchmark.<\/P>Note : Tous les jeux de données testés ne montreront pas nécessairement que le service utilise pleinement le CPU du niveau ArcGIS Server. Dans ces cas, un dépannage supplémentaire est nécessaire pour comprendre où se trouve le goulot d'étranglement limitant la scalabilité du flux donné.<\/STRONG><\/FONT><\/P>En règle générale, configurez la charge progressive maximale pour être 25 % -- 60 % supérieure au nombre de cœurs CPU du serveurComme montré ci-dessous, le Plan de Test est configuré pour s'exécuter pendant 1 heure et atteindre une charge progressive maximale de 40 threads concurrentsCela commencerait le benchmark avec 1 thread et ajouterait un thread supplémentaire toutes les 90 secondes<\/LI>Ce benchmark a été conçu pour tester un déploiement ArcGIS Server fonctionnant sur 24 cœurs CPU physiques <\/LI>Ajustez en conséquence, tous les serveurs ArcGIS ne fonctionneront pas sur 24 cœurs physiques et les valeurs maximales peuvent être trop élevées pour votre déploiement<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>
Note : Il est recommandé de noter les détails de la configuration progressive. Enregistrer cette information avec les résultats du test peut aider à donner un contexte et une signification appropriés à l'analyse ou aux conclusions.
Exécution du test Benchmark
Le benchmark doit être exécuté comme un plan typique Apache JMeter.
Voir le script runMe.bat inclus dans naturalearth1.zip pour un exemple sur comment exécuter un test recommandé par l'équipe Apache JMeter.
Note : Il est toujours recommandé de coordonner l'heure et la durée du test avec le personnel approprié. Cela garantit un impact minimal sur les utilisateurs et collègues qui pourraient également avoir besoin d'utiliser le Site ArcGIS Enterprise. De plus, cela aide à prévenir le bruit système provenant d'autres activités pouvant "polluer" les résultats.
Résultats et analyse
Une fois le test terminé, runME.bat ordonne à Apache JMeter de générer automatiquement un rapport pour aider à analyser les résultats.
Il existe des articles entiers et ressources internet dédiés exclusivement à analyser les composants des résultats d'un test charge. Pour simplifier, notre focus sera sur le débit des requêtes (requêtes/sec) et la performance des requêtes (secondes) extraits du rapport.
Les diagrammes ci-dessous illustrent les tendances idéales au fil du temps pour ces deux métriques.
La courbe idéale du débit
Idéalement, la courbe du débit aura la forme de la ligne orange ci-dessus. Le point où la courbe atteint son pic puis commence à s'aplatir indique que le système a atteint son niveau maximal (en raison d'un goulot matériel ou logiciel). Cette zone où la courbe se plie s'appelle le genou, et la valeur maximale y correspond.
La ligne bleue représente la charge progressive croissante durant le test.
La courbe idéale des performances
Idéalement, la courbe des temps réponse aura la forme verte ci-dessus. Elle est prise au même point que celui correspondant au débit maximal.
La ligne bleue représente la charge progressive croissante durant le test.
Rapport JMeter
Inclus dans naturalearth1.zip se trouve un rapport Apache JMeter nommé naturalearth1_run1 dans le dossier reports.
- L'ouverture du fichier index.html révélera plusieurs graphiques et tableaux aidant à l'analyse
Courbe réelle du débit
Du rapport :
Sous Charts->Throughput, on trouve le graphique Hits Per Second où est tracé le débit des requêtes issu du test
par seconde" est équivalent à la fois à transactions/sec et requests/sec- Le système a atteint un débit maximal d'environ 80 transactions/sec (ou 80 requests/sec)
Courbe de performance réelle
- Du rapport :
- Sous Charts-->Response Times, le graphique Time Vs Threads peut être trouvé où la performance des requests du test est tracée
- Tous les éléments sauf "/pvtserver/rest/services/NaturalEarth/MapServer/export" sont filtrés (en cliquant dessus dans la légende)
- Comme le test a été construit avec chaque transaction contenant une seule request, la "export request" représente également la performance moyenne de la transaction
- Au point de débit maximal, le système délivre une performance de transaction d'environ 314ms ou 0,3 secondes
Note : Une approche différente de l'analyse devra être adoptée pour un test de charge contenant des transactions avec plus d'une request
Comparer les résultats
Après avoir terminé le test de votre système avec les données fournies et le Test Plan, vous pouvez comparer les résultats avec ceux listés dans cet Article. Cela peut fournir une mesure approximative pour comparer deux systèmes.
- Pour télécharger le Test Plan Apache JMeter utilisé dans cet Article, voir : naturalearth1.zip
- Pour télécharger le sous-ensemble de données Natural Earth utilisé dans cet Article, voir : Natural_Earth_Test_Data
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.
