Benchmark ArcGIS Enterprise...L'Approche Originale
Il y a quelque temps, j'ai discuté de l'utilisation du jeu de données Natural Earth avec un test Apache JMeter préconfiguré pour évaluer les performances d'un déploiement ArcGIS Enterprise. Les résultats de ce test pouvaient ensuite être comparés à ceux d'autres déploiements pour obtenir une idée comparative des caractéristiques de performance et d'évolutivité du matériel sous-jacent. Cette approche présentait certains avantages :
- Natural Earth est un jeu de données SIG gratuit
- Disponible pour un usage public
- Complexité des données faible à modérée (facile à manipuler)
- Le plan de test comportait une charge progressive pour observer les capacités d'évolutivité
Bien que utile et un bon étalon, la composante évolutivité signifiait que le test durait généralement longtemps (ce qui ajoutait aussi une certaine complication). Je me demandais s'il existait un moyen plus simple de simplement mesurer les performances du matériel de traitement (par exemple, le CPU) mais toujours via ArcGIS Enterprise :
- Était-il possible d'utiliser JMeter uniquement d'un point de vue performance ?
- Pouvais-je créer un test pour évaluer ArcGIS Enterprise sans jeu de données FGDB ou géodatabase d'entreprise sous-jacent (ce qui devrait simplifier l'effort global) ?
Il s'avère que les réponses étaient oui !
Benchmark ArcGIS Enterprise...Une Approche Alternative
D'accord... je parle à moitié vrai. Le nouveau test benchmark ne dépend pas d'un service basé sur un jeu de données FGDB ou eGDB, mais nécessite quand même certaines données. Pour simplifier, les données (par exemple, des géométries pré-générées) sont simplement transmises via les éléments d'échantillon JMeter à une ressource ArcGIS qui n'a pas de jeu de données référencé en arrière-plan.
Alors, comment cela se fait-il ?
Par le biais du service éprouvé <\/SPAN>Geometry service. Le service de géométrie d'ArcGIS Server est une ressource intégrée qui donne accès à de nombreuses fonctions pour effectuer des opérations géométriques. Les calculs de ces opérations (comme buffer ou generalize) peuvent être simples ou complexes (selon ce que vous lui demandez). Du point de vue d'un analyste performance, il offre un excellent moyen d'évaluer le matériel CPU de la machine exécutant ArcGIS Server.<\/SPAN>
Note : Bien que le terme ArcGIS Enterprise inclue ArcGIS Server, ce benchmark sollicite principalement ce dernier (par exemple, ArcGIS Server). Une partie du trafic peut passer par l'ArcGIS Web Adaptor et une petite quantité d'authentification Portal for ArcGIS peut avoir lieu, mais par conception, la majeure partie du travail sera effectuée par ArcGIS Server.<\/STRONG>
Avantages d'utiliser le Geometry service
Le Geometry service existe dans ArcGIS Server depuis la version 9.3, il est donc omniprésent. Cela rend un test utilisant ce service facile et fiable. Comme les données pilotant le test sont placées dans les paires clé/valeur des requêtes, cela ajoute une portabilité (par exemple, aucun jeu de données à transporter).
Note : Bien que le Geometry service soit inclus dans ArcGIS Server depuis un certain temps, il est désactivé par défaut et ne fonctionne pas. Le service doit être démarré et partagé aux membres appropriés de Portal for ArcGIS avant d'exécuter le test.<\/STRONG>
Plan de Test Geometry_Functions_Benchmark
- Télécharger et ouvrir le plan de test dans Apache JMeter devrait ressembler à ceci :
- Ajustez les variables définies par l'utilisateur pour correspondre à votre environnement
Quels Types de Fonctions Devraient Être Testés ?
Pour un benchmark, la réponse courte est seulement quelques-unes. Ce plan de test particulier appelle seulement quelques opérations différentes... ainsi que les mêmes opérations de différentes manières (par exemple, en changeant les paramètres de requête pour obtenir intentionnellement une réponse différente). Cela apporte de la mutabilité afin que le test ne fasse pas toujours la même chose.
Voici un aperçu des opérations utilisées dans ce benchmark :
Performance Attendue du Test et des Opérations
Ce test comporte certaines opérations qui peuvent être rapides et d'autres qui prendront plus de temps. Cette vitesse variera selon le matériel. En fin de compte, nous voulons juste qu'ArcGIS Enterprise (par exemple, Server) fonctionne pendant quelques minutes afin d'avoir une idée des performances du traitement. Si chaque opération prenait 10 minutes (avec un test beaucoup plus long), le benchmark lui-même pourrait devenir trop long et moins pratique à utiliser.
Exemple d'Architecture de Déploiement
Ce test benchmark a été réalisé en laboratoire sur deux serveurs différents (exécuté une fois par serveur) :
- ArcGIS Enterprise -- Machine #1 (matériel plus ancien)
- Intel Xeon E5-4650, 2.70 GHz
- SPECint_base2006
- Score : 50.5
- 32 cœurs de traitement
- HyperThreading désactivé
- 64 Go RAM
- Réseau 10 Gbps
- ArcGIS Enterprise -- Machine #2 (matériel plus récent)
- Intel Xeon Gold 6126, 2.60 GHz
- SPECint_base2006
- Score : 71.9
- 24 cœurs de traitement
- HyperThreading désactivé
- 128 Go RAM
- Réseau 10 Gbps
P
Note : Comme cet effort de test était davantage axé sur la vitesse plutôt que sur le débit, les chiffres SPECint_base ont été utilisés au lieu des SPECint_rate_base.<\/strong>Exécution du Test Benchmark<\/H1 >< P >< FONT color = "#000000">Pour les tests longue durée, il n'est pas recommandé d'exécuter le plan de test via l'interface graphique. Cependant, comme ce test est relativement court, l'impact est minime.<\/FONT ><\/ P >< P >< FONT color = "#FF0000">< STRONG > Note : Lorsqu'on exécute un test, il est toujours recommandé de coordonner l'heure de début et la durée prévue avec le personnel approprié. Cela garantit un impact minimal sur les utilisateurs et autres collègues qui pourraient également avoir besoin d'utiliser le site ArcGIS Enterprise concerné (par exemple, le déploiement en production). De plus, cela aide à prévenir le brouillage système<\/EM> provoqué par d'autres activités et utilisations pouvant "polluer" les résultats du test.<\/STRONG ><\/FONT ><\/ P >< H2 id = "toc-hId-1420371181">Résultats<\/H2 >< P >Après avoir ajusté les variables définies par l'utilisateur pour pointer vers l'environnement approprié (Machine #1devlab05), le benchmark a été exécuté directement dans l'interface graphique JMeter. Les résultats peuvent être observés via l'élément View Results in Table :<\/ P >< UL >< LI >Pour plus de commodité, le plan de test calcule automatiquement la durée totale du test, directement dans le nom de la dernière opération< UL >< LI >Cela facilite l'observation du temps du benchmark depuis la table<\/ LI ><\/ UL ><\/ LI ><\/ UL >< P >< span class = "lia-inline-image-display-wrapper lia-image-align-center" image-alt = "jmeter_geometry_functions_benchmark_results_server1.png" style = "width: 999px;" >< img src = "https://us.v-cdn.net/6038851/uploads/images/114073i4CE3499080850BE2/jmeter_geometry_functions_benchmark_results_server1.png" role = "button" title = "jmeter_geometry_functions_benchmark_results_server1.png" alt = "jmeter_geometry_functions_benchmark_results_server1.png" \/ ><\/ P >< UL >< LI >Le plan de test a été ajusté pour pointer vers un serveur avec un matériel plus récent (Machine #2eistsrv05) et le benchmark a été relancé< UL >< LI >Depuis la table, les résultats sont ajoutés après la première exécution :<\/ LI ><\/ UL ><\/ LI ><\/ UL >< P >< SPAN >
<\/span><\/SPAN><\/P>Comme prévu, la première machine a nécessité plus de temps pour effectuer les mêmes opérations. Cela a entraîné une différence mesurable de performance entre les deux machines.<\/SPAN><\/P>Machine #1…devlab05Durée du benchmark : 259946 ms<\/LI><\/UL><\/LI>Machine #2…eistsrv05Durée du benchmark : 181441 ms<\/LI><\/UL><\/LI><\/UL>Calculer le changement en pourcentage<\/H2>Étant donné que les temps de réponse étaient plus bas (par exemple, plus rapides) avec du matériel plus récent (comparé à la première exécution sur du matériel plus ancien), nous allons calculer une diminution en pourcentage<\/EM> :<\/P>Premièrement, temps serveur original - temps serveur plus récent = la diminution<\/LI>Puis, la diminution ÷ nombre serveur original × 100 = le % de diminution<\/LI><\/UL>(259946 ms - 181441 ms) / 259946 ms = 0.302<\/P>0.302 x 100 = 30.2% <\/P>Les temps de benchmark du matériel plus ancien (notre point de départ) étaient inférieurs de 30 % par rapport au matériel plus récent<\/U>. Ce changement en pourcentage suggère une amélioration mesurable lors de l'utilisation du matériel plus récent.<\/P>Estimation du changement en pourcentage basée sur SPEC<\/H2>Utilisons le ratio SPEC avec le temps de benchmark de l'exécution originale pour prédire le target_time (temps de benchmark sur la machine plus récente). Cela peut aider à comprendre si un changement en pourcentage à peu près identique pourrait être estimé.<\/P>(Baseline_SPEC x Baseline_Time) = (Target_SPEC x Target_Time)<\/P>((Baseline_SPEC x Baseline_Time) / Target_SPEC) = Target_Time<\/P>(36.875 x 259946 ms) / 53.75 = 178335 ms (après arrondi à la seconde la plus proche)<\/P>(259946 ms - 178335 ms) / 259946 ms = 0.314<\/P>0.314 x 100 = 31.4%<\/P>D'après cette prédiction, le matériel plus ancien était estimé à être inférieur de 31 % par rapport au matériel plus récent. Cela est très proche du changement en pourcentage qui a été calculé sur la base des temps de benchmark observés.<\/U> <\/P>Matériel futur<\/H1>
<\/span>Les architectures processeur et les vitesses CPU s'améliorent constamment. Finalement<\/EM>, un tel test de benchmark (tel qu'il est actuellement construit) pourrait ne prendre qu'une minute ou quelques dizaines de secondes à s'exécuter (quel beau problème à avoir). À ce stade, la complexité pourrait être ajoutée au test pour augmenter sa durée d'exécution afin de mieux correspondre à la nouvelle technologie.<\/P>Vous avez peut-être remarqué que la dernière transaction dans le test a été désactivée. Cette requête Buffer de 1000 points avec une distance de 10000 mètres et une unité de 9035 (Distance internationale en mètres) prend un certain temps à calculer (même sur un matériel décent). Elle a été désactivée pour raccourcir le temps d'exécution à une durée raisonnable. Cependant, si cela est utile, elle peut être activée comme calcul supplémentaire, selon la vitesse CPU du déploiement concerné.<\/P>Réflexions finales <\/H1>Comme mentionné dans d'autres articles communautaires, il n'existe pas un seul service ou fonction qui puisse couvrir toute l'étendue et la profondeur d'ArcGIS. Cependant, le service Geometry est une ressource qui représente une partie du domaine incroyable des SIG facile à utiliser. Cela en fait une bonne option à utiliser pour les efforts de test de benchmark.<\/P>Un temps de réponse rapide dépend-il uniquement de la vitesse CPU ?<\/H2>Pour ce test de benchmark Geometry, oui. Cependant, pour les services réels, la vitesse de traitement n'est pas le seul facteur.<\/P>Les composants matériels du serveur tels que la vitesse du disque, la mémoire disponible, la vitesse réseau sont d'autres ressources qui peuvent améliorer les temps de réponse (en plus de la vitesse CPU). Ensemble, ils ont tous un effet positif sur l'expérience utilisateur.<\/P>Ce benchmark s'est concentré sur la performance CPU car c'est une grande partie du processus requête client / réponse serveur, mais comme mentionné précédemment, ce n'est pas la seule ressource serveur lorsqu'on prend en compte d'autres services ArcGIS potentiels.<\/P>Qu'en est-il des autres outils de comparaison CPU ?<\/H2>
<\/span>Il existe de nombreux utilitaires qui peuvent profiler et tester les différentes pièces du matériel serveur en utilisant toute une batterie d'exercices. Ces tests sont excellents et apportent certainement une valeur ajoutée pour comprendre le matériel. Encore une fois, il n'y a pas un test unique qui puisse représenter tout ce qui concerne les SIG. Mais espérons que ce Plan de Test Benchmark Geometry puisse être un outil utile dans la boîte à outils de l'analyste. <\/P>
<\/P>Pour télécharger le Plan de Test Apache JMeter utilisé dans cet article voir : geometry_functions_benchmark1.zip<\/A><\/STRONG> <\/P> <\/P>
<\/P>
<\/P>
Attribution<\/STRONG><\/P>Ressource :
File:Wikimedia_Foundation_Servers-8055_43.jpg<\/A><\/P>Description : Serveurs PowerEdge montés en rack de 11e génération<\/SPAN><\/P>Auteur :
Victorgrigas<\/A> - Travail personnel<\/SPAN><\/P>Créé : 16 juillet 2012<\/SPAN><\/P>Téléversé : 20 juillet 2012<\/SPAN><\/P>Licence : CC BY-SA 3.0<\/A>, Lien<\/A> <\/P> <\/P>
Ressource :
File:Cpu-processor.jpg<\/A><\/P>Description :<\/P>
Auteur :
Fx Mehdi<\/A> - Travail personnel<\/SPAN><\/P>Téléversé : <\/SPAN>30 mai 2019<\/SPAN><\/P>Licence : Creative Commons Attribution-Share Alike 4.0 International<\/A ><\/
