Le Pool d'Instances Shared Service
Lorsque les gens parlent de test de charge d'un Site ArcGIS Enterprise, ces conversations impliquent généralement la consommation de services de fonctionnalités dédiés ou hébergés.
Depuis de nombreuses années, les services dédiés et hébergés fournissent un mécanisme rapide et fiable pour consommer des ressources cartographiques à fort trafic en ligne. Cela n'a pas changé.
Cependant, il existe un autre type de ressource pour fournir des cartes aux utilisateurs : le Pool d'Instances Shared Service.
Introduit dans la version 10.7, le pool d'instances partagées facilite la visualisation et l'interrogation des services qui restent précieux mais où l'utilisation de la mémoire système est privilégiée par rapport à la performance.
Cette fonctionnalité permet une publication à haute densité de services (par exemple, pouvoir publier et avoir de nombreux services en cours d'exécution) au détriment d'une certaine vitesse et débit. Cela peut être un bon compromis étant donné que pour de nombreuses organisations, il y a généralement plus de candidats aux shared services que de services dédiés ou hébergés.
Grâce à cette caractéristique avantageuse, les shared services ont véritablement changé la donne. Mais, du point de vue du test de charge, certaines considérations sont à prendre en compte.
Note : En tant qu'administrateur SIG, supposez que tous les shared services ont une valeur égale entre eux. De plus, supposez que les services dédiés doivent avoir une priorité plus élevée que les shared services.
Les Shared Services Doivent-ils Être Testés en Charge ?
La question à 64 000 $ ! En tant qu'analyste performance, cette question peut se poser lors de la publication de vos services sur le Site.
Bien qu'il puisse être très tentant de tester en charge les shared services pour comprendre leur profil d'évolutivité, plusieurs raisons font que cette stratégie ne *fait pas* sens :
- Si l'évolutivité était primordiale, le service devrait être déplacé vers dédié
- Les shared services peuvent toujours évoluer (par exemple, supporter plusieurs requêtes simultanées pour le même élément) mais ce n'est pas leur fonction principale
- L'administrateur a déjà désigné le service pour privilégier l'utilisation mémoire
- En configurant le service comme shared, on s'attend à ce que le service ne soit pas fréquemment sollicité
- Si le service a occasionnellement des temps de réponse plus lents ou légèrement plus lents, cela est acceptable
- Tester ces services vole des ressources matérielles aux services dédiés
- Les services dédiés sont vos services "première classe", ne laissez pas les shared services rivaliser avec eux
- Les services dédiés et hébergés sont les mécanismes privilégiés pour l'évolutivité
- Les shared services ne le sont pas
- En testant ou en envoyant fréquemment des requêtes aux shared services, les ressources système (limitées) comme le CPU et la mémoire peuvent être détournées des services qui en ont besoin pour offrir une performance rapide aux utilisateurs
- Défis dans la gestion du plan de test
- Il n'est pas rare que les Sites aient des dizaines voire des centaines de shared services
- En supposant que tous les shared services soient égaux, le plan de test pour tester efficacement et profiler une centaine ou plus de shared services pourrait être décourageant et difficile à gérer
Un Site a un Mélange de Shared et Dedicated Services, Les Dedicated Peuvent-ils Toujours Être Testés ?
Oui. Comprendre le profil performance et évolutivité des dedicated services reste une information précieuse pour déployer et gérer le Site de manière optimale. Testez vos dedicated services comme vous le feriez normalement.
Les Shared Services Peuvent-ils Être Testés Si C'est Le Seul Type De Pool D'Instances Publié ?
Il n'y a aucune limitation technique empêchant les shared services d'être testés en charge.
Bien qu'il soit tout à fait possible d'effectuer un tel test, ce n'est pas recommandé pour les raisons évoquées ci-dessus.
Analyser et Surveiller Périodiquement le Site
La popularité des services peut augmenter ou diminuer avec le temps. Analyser périodiquement les schémas de trafic des requêtes de service peut aider les administrateurs à disposer d'informations pour configurer et gérer le Site de manière optimale. Cela signifie que lorsque certains services sont demandés plus fréquemment (ou qu'il est anticipé qu'ils le seront), ils peuvent être déplacés manuellement d'un service shared vers un service dédié.
