Au cours des cinq essais, il était évident que l’instance de base de données dotée de ressources insuffisantes lors du premier test dégradait de manière notable les performances système et l’expérience utilisateur. Une fois l’instance de base de données correctement dimensionnée pour nos charges de travail, les ratios ArcSOC : vCPU ont eu un impact moindre sur le temps d’exécution des processus. Dans le tableau ci-dessous, on peut constater que le ratio ArcSOC : vCPU égal à 1:1 imposait des temps d’attente supplémentaires (0,246s) sur les processus de visualisation, mais n’impactait pas significativement les processus de mise à jour (voir P99 Waits HS). Cela est probablement dû à des ArcSOC occupés sur le serveur d’hébergement.
Le ratio 2:1 générait des temps d’exécution des processus quasiment identiques sans attente significative, mais présentait une forte utilisation de la mémoire sur le serveur UN GIS Server (82 %). Le ratio 2:1 est trop élevé pour ces processus de mise à jour versionnés, où le nombre maximal d’ArcSOC sur le serveur UN GIS Server n’atteint que 7. Par conséquent, en augmentant le nombre d’ArcSOC sur le serveur UN GIS Server, nous ne faisons que gaspiller des ressources serveur. Cependant, le serveur d’hébergement, qui prenait en charge les processus en lecture seule, a facilement pris en charge le ratio 2:1. Le serveur UN GIS Server nécessite plus de mémoire pour prendre en charge les ratios 2:1 et au-delà. Avec le ratio 4:1, le serveur d’hébergement a aussi besoin de plus de mémoire.
Ces points sont spécifiques au système testé. Vous pouvez les utiliser pour étayer vos décisions de conception et de configuration, mais vous devez toujours surveiller et ajuster votre système en fonction de vos propres résultats.
Nous avons conclu que l’ajout d’un plus grand nombre d’instances de service ne permettait pas d’améliorer l’expérience utilisateur des éditeurs, bien que cela puisse améliorer la réactivité de nos processus de visualisation en réduisant les temps d’attente. Nous avons constaté que même les ArcSOC non utilisés consommaient toujours des ressources serveur. Le tableau ci-dessus montre une légère augmentation de la durée des processus à mesure que le ratio ArcSOC : vCPU croît.
Cela implique que les ArcSOC supplémentaires disponibles n’étaient pas nécessaires pour prendre en charge les demandes des utilisateurs et consommaient inutilement des ressources système (principalement la mémoire). Le tableau ci-dessus confirme que les processus de mise à jour n’ont pas tiré parti des ArcSOC supplémentaires, mais que les processus de visualisation, avec beaucoup plus d’opérations par heure, en ont bénéficié. Par conséquent, pour notre système, un ratio 2:1 d’ArcSOC par rapport aux vCPU était optimal pour les services en lecture seule sur le serveur d’hébergement, et 1:1 est optimal sur le serveur UN GIS Server.
Une instance de base de données dont les ressources étaient insuffisantes a eu un impact négatif sur l’ensemble du système :
Pour notre système, nous avons déterminé que la taille plus élevée de l’instance de la géodatabase (16 processeurs virtuels) était critique
Les ArcSOC, le processeur GIS Server et les instances Web Adaptor étaient occupés, ce qui donnait l’impression que les problèmes de performances impactaient l’ensemble du système
Les temps d’exécution des processus étaient approximativement deux fois plus longs qu’avec une base de données sous-dimensionnée
Une base de données avec des ressources insuffisantes avait un impact nettement plus important sur les performances que des instances de cartes mal configurées
La simple augmentation des ressources de base de données a considérablement amélioré le comportement et les performances du système
Avec une base de données aux ressources appropriées, l’augmentation du ratio d’ArcSOC (instances de service de carte) par rapport aux processeurs virtuels (vCPU) n’a pas permis d’améliorer l’expérience utilisateur ni la durée d’exécution des processus
Ajouter des instances de service inutiles peut avoir un impact négatif sur le système en consommant des ressources supplémentaires inutiles
Augmenter le nombre d’instances de carte en cours d’exécution aura un impact sur l’utilisation de la mémoire du serveur GIS Server, même lorsqu’elles ne sont pas occupées
La séparation des charges de travail reste importante. Les services d’entités qui exposent des données versionnées utiliseront plus de mémoire du serveur GIS Server que les services en lecture seule
Au minimum, surveillez le processeur de la base de données, l’utilisation d’ArcSOC, les ressources du serveur SIG Server et l’expérience utilisateur afin d’identifier la configuration optimale pour votre système, surtout après avoir effectué des modifications