Méthodes de test et résultats

Des tests manuels, combinés à des tests de charge automatisés, ont été menés pour examiner l’impact d’une mauvaise configuration de l’étendue de la carte et de la visibilité à l’échelle d’une couche sur les performances des processus de mise à jour et d’affichage et sur l’expérience utilisateur. Les instances des ordinateurs de bureau, ainsi qu’ArcGIS Pro et les applications Web, ont été surveillés pendant que les processus étaient exécutés sous charge.

Des tests par script ont été réalisés pour simuler les étapes suivies par un éditeur lors de l’exécution des processus définis. Une fois les tests terminés, les résultats ont été assemblés et analysés pour comparer l’utilisation des ordinateurs de bureau et l’efficacité de l’utilisateur final avec différentes configurations matérielles.

Méthodes de test

Pour tester l’impact que les étendues de carte et les plages de visibilité des couches peuvent avoir sur les performances et l’expérience utilisateur, quelques modifications ont été apportées à des cartes par ailleurs bien configurées qui avaient déjà été testées et dont les performances et l’expérience utilisateur avaient été confirmées :

  • Carte Web du tableau de bord (utilisée pour le processus d’affichage des ressources) : la visibilité de la « couche électrique » a été modifiée du niveau du quartier au niveau du comté, et l’étendue par défaut de la carte a été modifiée du quartier aux comtés.
  • Application Web Experience Builder (utilisée pour le processus de synthèse des ressources) : la visibilité de la couche de lignes électriques et l’étendue de la carte par défaut ont été mises à jour avec les mêmes paramètres que ci-dessus.
  • Carte du projet ArcGIS Pro (utilisée pour les processus de mise à jour) : suppression des plages de visibilité de la couche « conducteur moyenne tension » à l’intérieur du groupe de couches « ligne électrique » et définition de l’étendue de carte par défaut sur 1:500 000.

Ces modifications ont été sélectionnées pour voir l’impact des configurations de la visibilité des couches et de l’étendue de la carte sur différents types de processus de gestion des informations du réseau de distribution d’électricité. Le service de réseau de distribution en lecture seule utilisé pour les processus Viewer fonctionne sur le serveur d’hébergement, tandis que les processus de mise à jour utilisent le service UN hébergé sur le serveur SIG. Par conséquent, l’impact d’une visibilité de couche et d’une étendue de carte mal configurées sur les processus de mise à jour et d’affichage peut être observé sur l’instance du composant système correspondant.

Outils des tests de performance

ArcGIS étant un système multiniveau, des tests de performance ont été effectués au niveau du stockage, 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. Les requêtes ArcGIS Pro ont été enregistrées, puis rejouées pour simuler la charge, en plus des processus manuels qui ont été exécutés pour évaluer l’expérience de l’utilisateur final.

Le moniteur de performance de Windows et ArcGIS Monitor ont également été utilisés pour surveiller l’utilisation des ressources entre différents composants. Pour plus d’informations, consultez Outils des tests de performance.

Résultats des tests

Le système a été testé dans trois scénarios pour comprendre comment une mauvaise configuration de la carte affecte les performances et l’expérience utilisateur à différentes charges. Pour chaque scénario de charge, vous pouvez comparer l’impact par rapport à un système par ailleurs identique avec des plages de visibilité optimisées (à gauche). À un niveau élevé, les résultats des tests montrent que les cartes avec une ou deux configurations de visibilité de couche et d’étendue de carte inappropriées peuvent avoir un impact considérable sur l’utilisation du système et l’expérience utilisateur, en particulier à des charges plus élevées.

Scénario de test : charge de conception x2

Comparaison des plages de visibilité optimisées et sous-optimales à une charge de conception x2 Remarques :

  • Dans l’ensemble, utilisation acceptable sur tous les composants du système, mais avec une utilisation deux fois plus importante sur la base de données, Utility Network (UN) et les instances de serveur d’hébergement par rapport au système optimisé
  • Les serveurs d’hébergement et les serveurs UN présentent des pics d’utilisation du processeur tout au long de l’exécution
  • Les temps d’attente du service et l’utilisation d’ArcSOC restent dans des seuils acceptables

Scénario de test : charge de conception x4

Comparaison des plages de visibilité optimisées et sous-optimales à une charge de conception x4 Remarques :

  • Le serveur d’hébergement et la base de données présentent une utilisation significative des ressources tout au long du test, avec une utilisation environ quatre fois supérieure à celle du système optimisé
  • L’instance PostgreSQL affiche une augmentation de plus de 200 % de l’utilisation des ressources par rapport à une charge de conception x2
  • Les temps d’attente pour le service continuent d’augmenter
  • La plupart des ArcSOC sur le serveur d’hébergement sont occupés tout au long de l’exécution, avec des pics pour certaines instances
  • Les ArcSOC sur le serveur UN montrent une augmentation linéaire et progressive et sont moins impactés que le serveur d’hébergement

Scénario de test : comparaison entre charge de conception x8 (optimisée) et charge de conception x6 (sous-optimale)

Comparaison des plages de visibilité optimisées et sous-optimales, respectivement à une charge de conception x8 et x6 Remarques :

  • La configuration sous-optimale montre des performances globales médiocres avec des temps d’attente de service inacceptables, en particulier pour les charges de travail de la visionneuse s’exécutant sur le serveur d’hébergement
  • Dans la configuration sous-optimale, les serveurs d’hébergement présentent une utilisation environ quatre fois supérieure à la charge x6, même par rapport à une charge de conception x8 sur le système optimisé
  • L’instance PostgreSQL atteint son seuil à une charge x6 avec une configuration sous-optimale, ce qui représente plus du double de l’utilisation du système optimisé à une charge de conception x8
  • La plupart des ArcSOC sur le serveur d’hébergement atteignent des seuils maximaux avec une configuration sous-optimale ; un comportement inhabituel est observé en raison de l’occupation du serveur et de l’incapacité à récupérer les valeurs d’utilisation du SOC
  • Les ArcSOC sur le serveur UN (éditeurs) montrent une augmentation linéaire et progressive et sont moins impactés que le serveur d’hébergement

Comparaison de l’utilisation d’ArcSOC

L’augmentation de l’utilisation d’ArcSOC entraîne souvent une augmentation du temps d’attente du service, ce qui a un impact sur la capacité des utilisateurs à travailler efficacement. L’utilisation d’ArcSOC a été surveillée dans tous les scénarios de charge. Dans chaque test, l’utilisation d’ArcSOC était nettement supérieure à celle du système avec des cartes optimisées. Les diagrammes ci-dessous illustrent la différence significative avec une charge de conception x4. Par rapport au système optimisé, l’utilisation d’ArcSOC sur le serveur d’hébergement est multipliée par environ 3 ou 4 et celle du serveur UN par environ 2.

Comparaison de l’utilisation d’ArcSOC entre les plages de visibilité optimisées et sous-optimales

Expérience utilisateur

Pour évaluer l’expérience utilisateur, la durée des étapes du processus a été capturée. Lorsque les processus prennent plus de temps à s’exécuter, cela indique que le système répond plus lentement à leurs demandes. Le diagramme ci-dessous montre le temps moyen nécessaire aux utilisateurs pour effectuer une étape donnée d’un processus, dans les systèmes optimisés et sous-optimaux.

Comparaison des temps d’exécution des étapes du processus à l’aide de cartes configurées de manière optimisée et sous-optimale

Dans tous les processus autres que la gestion de la charge, on observe une augmentation mesurée de la durée totale du processus lorsque la charge augmente. Avec une charge de conception x6, le processus d’affichage des ressources prend environ quinze fois plus de temps qu’avec une charge de conception x2. Les étapes de connexion et d’ouverture du projet dans les processus électrique et de mise à jour de la ressource sont celles qui prennent le plus de temps, avec des sauts notables de durée à mesure que la charge sur le système augmente. De plus, les étapes de localisation, de zoom sur l’appareil et de traçage en aval présentent toutes des sauts exponentiels de durée avec une charge de conception x6 par rapport à une charge de conception x4.

Top