Résultats des tests sur l’impact des ressources de base de données

Lors de notre premier ensemble de tests, nous avons examiné l’impact des ressources de base de données sur la capacité du système à gérer la charge, même avec suffisamment de ressources serveur GIS Server. Ces tests visent à montrer l’impact de la base de données sur l’ensemble du système. En d’autres termes, si vos utilisateurs rencontrent des temps d’attente prolongés, le problème ne réside pas forcément uniquement au niveau d’ArcGIS Server.

Méthodes de test et résultats

Nous avons réalisé deux tests pour comparer l’impact des ressources de base de données sur les performances du système, même avec suffisamment de ressources serveur :

• d’abord en utilisant une instance de machine virtuelle de base de données de petite taille, avec 8 processeurs virtuels (vCPU)
• puis avec une instance de machine virtuelle de base de données de plus grande taille, avec 16 processeurs virtuels (vCPU)

Nous avons conservé tous les autres aspects du système, avec une configuration ArcSOC 1:1. En d’autres termes, un ArcSOC configuré par processeur virtuel (vCPU) sur l’instance ArcGIS Server, où le nombre d’ArcSOC et de processeurs virtuels est égal. Nous avons capturé et surveillé 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 ) pour é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é (par rapport à nos études test précédentes) afin de garantir une charge suffisante pour impacter le système.

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.

Test de charge 1 : instance de base de données de petite taille – 8 processeurs virtuels (vCPU)

Ce test a été exécuté avec 8 processeurs virtuels disponibles sur l’instance PostgreSQL afin d’observer l’impact système sur un serveur de base de données réduit. Le serveur GIS Server ArcGIS (UN Server) a également été équipé de 8 processeurs virtuels. Les six graphiques de ressources d’instance ci-dessous illustrent l’utilisation des ressources dans le système et un graphique illustre des requêtes simultanées. Dans chacun des graphiques de ressources, les lignes en orange représentent le pourcentage d’utilisation du processeur, les lignes en couleur or le pourcentage d’utilisation du disque et la ligne en violet le pourcentage d’utilisation de la mémoire.

Dans le diagramme ci-dessous, vous voyez que le processeur de la base de données PostgreSQl s’exécute à 100 % et que le processeur du serveur d’hébergement présente fréquemment des pics allant jusqu’à 100 %. Cela s’explique par le nombre élevé de requêtes de consultation associées aux processus à la charge de conception 8x.

Le graphique du bas montre les requêtes simultanées, mesurées à partir des journaux JMeter. Remarquez que la ligne rouge, qui représente les requêtes de consultation simultanées, présente une tendance à la hausse allant jusqu’à 538 à mesure que le test s’exécute. Cela indique que les requêtes ne se ferment pas. Dans les graphiques ultérieurs, vous verrez cette ligne bouger régulièrement vers le haut et vers le bas, ce qui indique que le système répond et que les requêtes se ferment assez rapidement pour gérer la charge.

Cette configuration ne prenait pas en charge la charge, car les ressources du serveur de base de données étaient insuffisantes, comme en témoignent la quantité d’orange (utilisation du processeur) dans le graphique de base de données PostgreSQL, les pics de processeur du serveur d’hébergement et le nombre de requêtes simultanées.

Pour aller plus loin, le graphique ci-dessous représente l’utilisation d’ArcSOC sur le serveur d’hébergement, telle que capturée par l’utilitaire Soccer (surveillance ArcSOC), qui s’exécute sur une machine distante. La ligne rouge montre les ArcSOC occupés à 100 % (8), probablement attribués à la base de données surchargée. Les ArcSOC sont retenus (occupés) en attendant la réponse de la base de données. En fait, les ArcSOC étaient tellement occupés que Soccer n’a pas pu suivre leur état, comme en témoignent la ligne rouge incomplète et les chutes soudaines du nombre maximal (ligne verte).

Test de charge 2 : instance de base de données de grande taille – 16 processeurs virtuels (vCPU)

Lors du second test, nous avons doublé l’instance de la base de données PostgreSQL à 16 processeurs virtuels (vCPU) afin d’observer les différences possibles par rapport au premier test. Les serveurs SIG ArcGIS sont restés pourvus de 8 processeurs virtuels chacun. Comme dans le diagramme précédent, le pourcentage d’utilisation du processeur est en orange, du disque est en couleur or et de la mémoire est en violet. Vous pouvez remarquer qu’en dehors de quelques pics, tous les serveurs s’exécutent généralement à une capacité inférieure à 60 % du processeur, du disque et de la mémoire.

Le graphique des requêtes simultanées montre en moyenne 36 requêtes de consultation simultanées, avec quelques pics. Les requêtes ouvertes ne sont pas en hausse comme dans le graphique précédent, ce qui indique que ce système gère la charge.

Le graphique ArcSOC ci-dessous montre que les ArcSOC sur le serveur d’hébergement sont occupés, mais la réponse globale du système est satisfaisante. Même si 99 % (p99) de l’utilisation correspond à 8 SOC (conteneurs d’objets) ou moins, la moyenne est de 4,81. Plus tard, nous examinerons l’expérience utilisateur pour voir si le système permet aux personnes de travailler efficacement.

Expérience utilisateur

En plus de l’utilisation globale du système et des performances, les ressources accrues disponibles sur l’instance de base de données ont considérablement amélioré la capacité de l’utilisateur final à mener à bien son travail efficacement. Cette étude test a évalué l’efficacité de l’utilisateur final en observant les temps d’exécution du processus (combien de temps met un utilisateur pour accomplir les étapes du processus), ainsi que les temps d’exécution des étapes du processus (combien de temps a été nécessaire pour accomplir une étape clé dans un processus).

Le graphique ci-dessus indique comment une saturation accrue des ressources système lors du test de base de données de petite taille entraîne des temps d’exécution plus longs, ce qui génère une expérience globale dégradée pour l’utilisateur final. Le temps d’exécution global de tous les processus a augmenté de manière significative avec une base de données aux ressources incorrectes par rapport à une base de données aux ressources appropriées, même lorsque les ressources d’ArcGIS Server étaient suffisantes. En particulier, le processus Afficher les ressources a vu une diminution spectaculaire du temps d’exécution du processus avec une géodatabase d’entreprise de taille adéquate.

En plus du temps d’exécution du processus, nous pouvons observer plus en détail l’impact des ressources de base de données sur la durée de certaines étapes du processus de mise à jour. Cela montre cependant la grande différence de durée pour ouvrir un projet et localiser une ressource dans le processus Mettre à jour la ressource. De même, Traçage électrique a présenté une augmentation significative à toutes les étapes du processus. Ce modèle s’est poursuivi pour tous les processus capturés.