Résultats des tests sur l’impact de la configuration d’ArcSOC

En plus d’évaluer les ressources de base de données, le second ensemble de tests visait à identifier la configuration optimale d’ArcSOC pour prendre en charge une charge de conception 8x sur notre système et ses processus, en supposant que les ressources de la base de données soient suffisantes.

Méthodes de test et résultats

Trois tests ont été réalisés avec différents ratios d’ArcSOC par rapport aux processeurs virtuels (vCPU) :

• 2:1, or two ArcSOCs per vCPU on the ArcGIS Server instances
• 3:1, or three ArcSOCs per vCPU on the ArcGIS Server instances
• 4:1, or four ArcSOCs per vCPU on the ArcGIS Server instances

Nous avons également réalisé ce test avec un ratio d’ArcSOC par processeur virtuel de 1:1, que vous pouvez voir dans le test d’instance de base de données de grande taille, décrit dans Évaluation d’impact des ressources de la base de données.

Nous avons exécuté plusieurs tests de charge, en variant systématiquement le ratio d’instances ArcSOC par rapport aux processeurs virtuels afin d’observer et de mesurer les impacts sur les performances et l’expérience utilisateur. Tous les autres aspects du système ont été conservés pour obtenir des résultats significatifs.

Des indicateurs de performance tels que l’utilisation et la disponibilité d’ArcSOC, les temps d’attente des services, l’utilisation des ressources système et les taux d’erreur ( error ), ont été surveillés dans le but d’évaluer chaque configuration.

Les tests ont été réalisés avec 8 fois (8x) la charge de conception de l’étude test du système d’origine, et les ressources serveur ArcGIS Enterprise ont été réduites de moitié afin de garantir une charge suffisante pour impacter le système. JMeter a été utilisé pour simuler les processus utilisateur et mesurer les performances du système sous différentes charges.

ArcGIS étant un système multiniveau, des tests ont été effectués au niveau du client, du service et du stockage de données, ainsi que sur l’infrastructure sous-jacente. Dans cette étude test, JMeter a été utilisé pour simuler les processus utilisateur et mesurer les performances du système sous différentes charges.

2:1 ArcSOCs : vCPU ratio

Dans ce test, nous avons configuré deux ArcSOC par processeur virtuel sur les instances ArcGIS Server. Dans ce cas, 16 ArcSOC en cours d’exécution pour 8 processeurs virtuels. Comme dans les graphiques précédents, le pourcentage d’utilisation du processeur est en orange, du disque est en couleur or et de la mémoire est en violet.

Dans le graphique ci-dessous, le processeur pour toutes les machines est généralement à une capacité inférieure à 60 %. Vous pouvez cependant voir que l’utilisation de la mémoire sur le serveur UN GIS Server atteint un pic de plus de 80 %. Cela est dû aux ArcSOC en cours d’exécution supplémentaires par rapport à un ratio de 1:1. Les services sur le serveur UN GIS Server permettent la mise à jour de bases de données versionnées. Bien que le système semble fonctionner de façon fluide, la mémoire devra être étroitement surveillée pour éviter tout problème. Le graphique des requêtes simultanées montre les requêtes de consultation simultanées (en rouge) qui s’ouvrent et se ferment régulièrement, avec une moyenne égale à 35.

Le graphique ci-dessous montre l’utilisation d’ArcSOC pour le serveur d’hébergement, où 16 ArcSOC sont en cours d’exécution (la ligne bleue est couverte par la ligne verte), le nombre maximal d’ArcSOC utilisés (occupés) étant de 14. Le serveur UN GIS Server (non illustré) disposait d’un maximum de 7 ArcSOC occupés, il n’a donc pas tiré parti des instances de service supplémentaires, où 16 ArcSOC étaient en cours d’exécution, mais étaient pour la plupart inactifs. Comme ce serveur présentait une utilisation de la mémoire excédentaire de 80 %, la réduction des instances de service à min/max 8 sur le serveur UN GIS Server peut alléger une partie de la pression mémoire et rendre ce système optimal pour ces processus et charges. Tout changement dans les processus ou les charges est susceptible d’affecter l’équilibre.

3:1 ArcSOCs to vCPU ratio

Dans ce test, nous avons configuré trois ArcSOC par processeur virtuel. Dans ce cas, 24 ArcSOC en cours d’exécution sur 8 processeurs virtuels. Encore une fois, l’utilisation du processeur (en orange) est généralement inférieure à 60 % sur toutes les machines. Malheureusement, l’utilisation de la mémoire (en violet) sur le serveur UN GIS Server atteint son maximum, avec des chutes à 95 % dans le cadre du processus de nettoyage. Les requêtes de consultation simultanées (en rouge) montrent qu’elles s’ouvrent et se ferment régulièrement, avec une moyenne égale à 36. Ce système semble gérer la charge, mais il n’est pas viable à cause d’un manque de mémoire.

De plus, en regardant le graphique ArcSOC ci-dessous, vous pouvez voir qu’avec un ratio de 3:1, le serveur UN GIS Server dispose de 24 ArcSOC en cours d’exécution (la ligne bleue est couverte par la ligne verte). Le nombre maximal d’ArcSOC est toutefois limité à 18, qui consomment de la mémoire même lorsqu’ils ne sont pas utilisés. Ceci un exemple de configuration inappropriée. Notre charge de travail n’a pas besoin de tous les ArcSOC disponibles. Les six qui ne sont pas nécessaires (24 en cours d’exécution moins 18 qui sont occupés) consomment inutilement des ressources (mémoire). L’augmentation de la mémoire sur le serveur UN GIS Server peut améliorer cette situation, mais cela risque également de déplacer le problème vers le processeur ou la base de données. Vous devez réaliser des tests et des observations afin d’effectuer des choix de configuration et de conception appropriés à la prise en charge du système.

4:1 ArcSOCs to vCPU ratio

Dans ce test, quatre ArcSOC ont été configurés par processeur virtuel. Dans ce cas, 32 ArcSOC s’exécutent pour 8 processeurs virtuels sur le serveur UN GIS Server. L’utilisation du processeur (en orange) augmente, avec deux pics supérieurs à 80 % sur le serveur UN GIS Server. Cependant, le plus gros problème est une utilisation quasi totale de la mémoire (en bleu) sur cette instance, où même le processus de nettoyage peine à suivre.

Les requêtes de consultation simultanées (en rouge) en bas montrent qu’elles s’ouvrent et se ferment toujours régulièrement, avec la même moyenne égale à 36, comme pour le ratio 3:1. Cela montre que les ArcSOC supplémentaires n’apportent aucun bénéfice aux performances du système ni à l’expérience utilisateur. Au contraire, ils consomment simplement les ressources du serveur SIG.

Cela est confirmé par le graphique ArcSOC ci-dessous qui montre un maximum de seulement 16 ArcSOC occupés. Nous pouvons voir ici clairement comment l’ajout d’instances de service supplémentaires n’a consommé que des ressources serveur inutiles, sans apporter de gains en termes de performances ou d’expérience utilisateur. Augmenter le processeur et la mémoire du serveur UN GIS Server peut contribuer à améliorer les résultats, mais cela risque de déplacer le problème vers le processeur du serveur de base de données. Il est essentiel de réaliser des tests et des observations.