Stratégies recommandées pour les tests de charge d'un déploiement ArcGIS Server
- Commencez par un plan de test
La plupart des logiciels de test peuvent produire un type de rapport une fois le test terminé. Ce rapport doit répondre aux questions posées par le plan de test.
Par exemple :
a) Le service ArcGIS pouvait-il utiliser tout le CPU (par exemple, lié au CPU) ?
b) Le service ArcGIS pouvait-il fournir un débit spécifique (par exemple, un certain nombre de transactions/sec) ?
c) Le débit a-t-il permis d'obtenir un temps de réponse moyen conforme à notre exigence de performance ?
Définir un objectif pour un test aide à maintenir l'effort de test concentré sur un but.
- Les tests doivent être effectués sur une application sans bogues ou défauts majeurs connus
Les tests de charge ne doivent pas être utilisés pour tester fonctionnellement un déploiement ou une application.
Une application doit passer les tests d'assurance qualité (QA) avant que les tests de charge ne soient effectués.
De plus, si une application contient des bogues majeurs, ces déficiences pourraient avoir un impact mesurable sur la performance et la scalabilité des services offerts. Cela annulerait très probablement les résultats du test et pourrait potentiellement faire perdre du temps, de l'argent et des ressources.
- Interagissez avec votre application (et les services ArcGIS) avant de les tester en charge
Si vous êtes le seul utilisateur sur votre système et que les services ArcGIS répondent très lentement, il n'est pas nécessaire d'effectuer un test sous charge. L'étape suivante devrait être d'ajuster et d'optimiser les services ArcGIS pour la performance.
- Coordonnez l'exécution des tests
Souvent, un test de charge est effectué dans un environnement QA/Staging ou Test mais peut parfois être réalisé en Production.
Quel que soit l'environnement, il est important de se rappeler que souvent, les services et ressources sont également consommés par d'autres utilisateurs (et pas seulement par l'équipe de test de charge).
Pour éviter toute confusion et expériences inattendues, il est fortement recommandé de coordonner l'exécution de tout test de charge avec le personnel approprié.
Cela peut aider à offrir une meilleure expérience aux utilisateurs réels et éviter du bruit indésirable dans un test de charge (provenant des actions que pourraient faire les utilisateurs réels).
- Vérifiez que l'environnement Test correspond aux attentes
Parfois, l'environnement Test peut être réduit pour diverses raisons. Puis, avec le temps, Test et Production deviennent des environnements très différents. Dans ce cas, les résultats des tests issus de Test auraient peu de signification par rapport à la façon dont Production va performer ou évoluer.
Par exemple :
a) Si Production est censé être déployé en utilisant une architecture hautement disponible alors Test devrait l'être aussi
b) Si Production est censé utiliser une géodatabase d'entreprise contenant 500 Go de données vectorielles alors Test devrait aussi
c) Si Production utilise des ArcGIS Servers avec 32 cœurs et que les maximums d'instances de service sont réglés à 32, alors Test devrait aussi
Maintenir les environnements Test et Production synchronisés peut aider à fournir la meilleure valeur (et attente) sur les résultats. Dans les cas où ils ne correspondent pas consciemment, notez-le avant que le test ne commence et dans toute conclusion dérivée de l'environnement Test.
- Commencez un test de charge à l'étape 1
Utiliser 1 comme étape initiale de charge peut aider votre analyse post-test.
L'étape 1 (ou un thread de test concurrent) représente le meilleur scénario possible pour votre test. C'est votre référence et c'est une bonne base pour comprendre à quel point le service ArcGIS s'est bien ou mal adapté à mesure que la pression augmentait (par exemple lorsque des threads supplémentaires étaient ajoutés).
- Collectez l'utilisation matérielle de toutes les machines impliquées dans le test
La plupart des frameworks de test offrent généralement la possibilité de collecter l'utilisation matérielle des serveurs et du client de test lui-même. Cela peut être précieux pour comprendre la consommation des ressources et identifier les goulets d'étranglement (par exemple, les ressources sur le client de test peuvent aussi être un facteur limitant).
Cependant, malgré cette fonctionnalité dans le logiciel de test, collecter l'utilisation matérielle n'est pas toujours possible en raison des permissions ou accès réseau (par exemple connexion via pare-feu/routeurs).
Bien qu'obtenir cette information directement via un framework de test soit certainement pratique, il existe d'autres moyens d'accomplir cette tâche. Utiliser des outils gratuits comme PerfMon sous Windows ou dtstat sous Linux pour capturer ces données est une étape supplémentaire mais qui vaut l'effort. Une fois le test terminé, une analyse peut toujours être réalisée sur les données graphiques créées manuellement à partir de l'utilisation matérielle.
- Testez d'abord les services ArcGIS individuels
Si une application web spécifique utilise plus d'un service ArcGIS, testez et optimisez chacun séparément.
Cette approche facilite l'identification des services pouvant avoir des goulets d'étranglement ou limitations qui empêchent leur utilisation optimale du matériel disponible.
Si un service ArcGIS ne peut pas utiliser tout le matériel CPU disponible du serveur ArcGIS Server, le testeur/analyste doit informer la personne appropriée qu'une opportunité d'optimisation existe dans le déploiement.
Évitez également de commencer l'effort de test avec le flux complet de l'application car il peut être difficile d'identifier les goulets d'étranglement potentiels lorsque plusieurs services ArcGIS sont testés simultanément.
- Testez aussi physiquement proche du déploiement que possible
Essayez d'éviter que le test "simule" Internet. Tester aussi physiquement proche du déploiement que possible peut aider à fournir la meilleure compréhension de ce que le matériel serveur peut délivrer.
Introduire volontairement une latence réseau ou une bande passante faible ajoutera du bruit au test et rendra difficile la reconnaissance pleine capacité des services ArcGIS et des serveurs sur lesquels ils fonctionnent.
- Durée des étapes et du test
Les tests n'ont pas besoin de durer 8 heures pour fournir des informations utiles sur le service ArcGIS concerné. Cependant, il est également recommandé d'éviter qu'un test de charge soit trop court. Il s'agit donc de choisir une durée (et pour chaque étape) qui fournit la bonne quantité d'informations. En d'autres termes, il s'agit d'enregistrer suffisamment d'échantillons de requêtes pour obtenir une moyenne "bonne".
La durée utilisée est généralement liée à votre temps de réponse ; un temps rapide peut délivrer beaucoup de requêtes avec une étape de charge de 5 minutes. Un temps lent peut nécessiter une étape de charge de 15 minutes pour enregistrer autant de valeurs.
En tant que testeur, vous ne réussirez pas toujours du premier coup la durée des étapes et du test et devrez peut-être ajuster puis relancer le test.
- Soyez attentif au niveau du journal ArcGIS Server
Bien que les journaux ArcGIS Server puissent fournir beaucoup d'informations à analyser, il est important de comprendre que les niveaux élevés VERBOSE et DEBUG peuvent ralentir la performance d'un site très occupé et ne sont pas recommandés en environnement Production. Tandis que la valeur WARNING (par défaut) offre la meilleure performance possible car elle n'enregistre que les avertissements et erreurs.
Cependant, un réglage FINE est un bon compromis entre informations analytiques utiles (comme les temps écoulés sur les requêtes dynamiques) et rapidité.
- Les services ArcGIS traditionnels peuvent être optimisés dans (ArcGIS) Server
Avant de tester en charge un service traditionnel (par exemple dédié) ArcGIS pour l'optimiser ou comprendre ses performances, essayez de régler sa valeur maximale d'instance ArcSOC au nombre total des cœurs CPU disponibles sur ArcGIS server.
Après avoir redémarré le service, ce réglage permettra à plusieurs requêtes simultanées de tirer parti du matériel disponible et ainsi montrer ses capacités sous son meilleur jour (en supposant que le service soit lié au CPU).
style="padding-left : 30px;">Augmenter la valeur maximale de l'instance ArcSOC permettra également au service d'utiliser plus de CPU mais, en contrepartie, plus de mémoire également. Veuillez vous assurer qu'il y a suffisamment de mémoire disponible sur la machine ArcGIS Server pour accueillir cet ajustement. Si le service n'est pas fortement sollicité, les instances supplémentaires deviendront inactives (par défaut après 1800 secondes) et elles s'arrêteront afin de libérer la mémoire du serveur.<\/P>
De même, augmenter le minimum d'une instance de service (pour correspondre au maximum) est une bonne stratégie pour obtenir des performances prévisibles. Cela est recommandé pour les services les plus populaires, mais gardez à l'esprit qu'une telle configuration consommera toujours de la mémoire (pour ce service) puisque aucune instance ne s'arrêtera après l'expiration du temps d'inactivité.<\/P>
Les services partagés ont également des paramètres d'instance qui pourraient être ajustés. Cependant, si un service partagé est suffisamment populaire pour être testé en charge, il devrait être configuré pour fonctionner comme un service traditionnel et dédié.<\/P>
- Tous les services ArcGIS ne sont pas limités par le CPU<\/STRONG><\/LI><\/UL>Si un service ArcGIS est limité par le CPU, cela signifie que la quantité de débit qu'il peut fournir (ou la capacité qu'il peut supporter) est uniquement limitée par le nombre de CPUs sur la ou les machines ArcGIS Server. À bien des égards, cela peut être une bonne chose.<\/P>Cependant, ce n'est pas toujours le cas. Parfois, vous pouvez avoir des goulets d'étranglement dans d'autres matériels comme le réseau, par exemple. Occasionnellement, vous pouvez rencontrer un goulet d'étranglement dans un composant logiciel qui peut être intentionnel ou non.<\/P>Par conséquent, la collecte des métriques matérielles pendant le test est très importante. Observer l'utilisation du CPU, de la mémoire, du réseau et du disque peut aider à fournir à l'analyste/testeur des informations vitales pour comprendre s'il y a quelque chose qui limite l'évolutivité du service ArcGIS Server et si c'est le matériel du serveur ou celui du client de test.<\/P>Tout est une question de débit (pas d'utilisateurs)<\/STRONG><\/LI><\/UL>Le débit est mesuré, les utilisateurs sont calculés... ce sont deux artefacts différents d'un test.<\/P>Dans un test, le débit est généralement défini comme transactions/seconde (ou opérations/seconde), et c'est une valeur qui doit être mesurée par le logiciel client de test. D'autre part, la définition d'un « utilisateur » peut varier mais c'est quelque chose qui est généralement calculé à partir du débit.<\/P>Puisque le débit est observé directement à partir des résultats d'un test de charge, c'est l'une des meilleures métriques pour déterminer l'évolutivité d'un déploiement.<\/P>Dans une note connexe, un thread de test (par exemple l'élément qui augmente en correspondance avec une pression accrue ajoutée à un test de charge) n'est pas non plus identique à un utilisateur. Le nombre de threads de test utilisés et leur durée sont généralement configurés dans la définition de charge progressive d'un test.<\/P>Vérifiez que le test a réussi<\/STRONG><\/LI><\/UL>La fin d'un test ne signifie pas nécessairement qu'il était « bon » et capable de répondre avec succès aux questions du plan de test. Il est important de vérifier et valider que le test envoyait les bonnes requêtes là où il devait et obtenait les réponses attendues.<\/P>Un contrôle qualité manuel rapide (QC) de la composition des requêtes dans le test peut aider pour cela.<\/P>Surveiller la longueur moyenne du contenu (par réponse) peut aider pour cela aussi.<\/P>La plupart des logiciels de test fournissent un « pourquoi » pour capturer la longueur moyenne du contenu (ou quelque chose de similaire). La règle générale est que la valeur moyenne pour cette métrique doit rester relativement constante tout au long du test. Si elle augmente ou diminue drastiquement, une enquête plus approfondie est recommandée car la réponse attendue aux requêtes pourrait ne pas revenir (par exemple erreurs au lieu d'image ou contenu json) ou si la réponse est valide mais très variable, une conception différente du test pourrait être nécessaire.<\/P>De plus, il est important de déterminer si les requêtes elles-mêmes ont réussi (par exemple HTTP 200). Certains logiciels de test peuvent permettre à l'analyste de configurer des vérifications de validation sur les réponses dans le test lui-même. Cela dit, le profilage de la métrique longueur moyenne du contenu fournit généralement une vue plus précise sur la réponse attendue du serveur.<\/P>Les résultats des tests ne garantissent pas le support pour X nombre d'utilisateurs<\/STRONG><\/LI><\/UL>Les résultats des tests ne valident que le flux testé. Ce flux testé montrera un débit pour un type spécifique de requête avec un temps de réponse correspondant. Il ne promet ni ne garantit que le déploiement supportera X nombre d'utilisateurs.<\/P>Rappelez-vous que la définition d'un utilisateur peut varier et signifier différentes choses selon les déploiements.<\/P>Évitez de tester des ressources partagées comme ArcGIS Online ou Google Maps<\/STRONG><\/LI><\/UL>Les offres gratuites et publiques des services ArcGIS Online ou Google Maps sont destinées à la « communauté ». Ces ressources sont assez robustes et évolutives mais ne peuvent pas être optimisées en termes de performance pour chaque utilisateur.<\/P>Puisqu'elles ne font pas directement partie d'un déploiement sur site, elles doivent être considérées comme une ressource « externe ». En conséquence, les requêtes vers elles doivent être retirées d'un test de charge car le test doit se concentrer uniquement sur les capacités de son propre matériel.<\/P>Résultats répétables<\/STRONG><\/LI><\/UL>Si les résultats d'un test de charge contre un service ArcGIS Server montrent des tendances similaires entre les exécutions (par exemple le même débit atteint à peu près au même moment durant le test), la ressource est généralement considérée comme « stable ». Pouvoir répéter les résultats d'un test est une bonne caractéristique.<\/P>Lorsque les résultats ne sont pas immédiatement répétables, l'analyste/testeur doit creuser plus profondément et essayer de comprendre ce comportement incohérent. Il se peut que le matériel ait été utilisé pour traiter des requêtes autres que celles du test (par exemple un autre utilisateur sur le système). Ou bien, si le déploiement était sur une infrastructure partagée (par exemple virtualisation), le matériel sous-jacent était utilisé à une autre fin (d'autres machines virtuelles exécutaient des tâches gourmandes en ressources). Dans ces cas-là, effectuer les tests de charge en heures creuses pourrait donner des résultats plus reproductibles montrant que le service a le potentiel d'être stable.<\/P>La conception des tests/flux doit être réaliste et basée sur ce qui serait attendu d'un utilisateur<\/STRONG><\/LI><\/UL>Évitez théories et projections ; concentrez-vous simplement sur comment l'utilisateur devrait utiliser l'application...le flux anticipé.
Le test de charge peut être facile à faire mais il peut aussi être facile d'élargir la portée du test pour inclure des scénarios inutiles ou peu probables.<\/P>Comprenez la valeur<\/STRONG><\/LI><\/UL>Souvent, le chemin vers un bon test utile est aussi important que le test lui-même. En tant qu'analyste cela vous aide:<\/P>a) Valider les procédures de test<\/P>b) Avoir la meilleure capacité à expliquer les résultats ce qui rend votre test précieux<\/P> 1) Certaines personnes ne demanderont pas seulement les résultats mais aussi l'analyse et les conclusions<\/P> 2) Soyez prêt à étayer ces conclusions avec des données<\/P>Restez simple<\/STRONG><\/LI><\/UL>Parfois, les efforts de test les plus informatifs sont simples et pas trop complexes.<\/P>
