Méthodes de test et résultats

Des tests visant à vérifier le bon fonctionnement de la conception et sa prise en charge des processus, des utilisateurs et de la charge prévue ont été réalisés. Les tests système permettent d’identifier les problèmes et de les corriger lors du déploiement du système dans des environnements inférieurs, idéalement avant qu’ils n’apparaissent en phase de production. Pour cette étude test, l’accent a été mis sur les performances du système et sur l’expérience de l’utilisateur final.

Chaque composant a été surveillé pendant l’exécution des processus sur différents scénarios de charge. Une fois les tests terminés, les résultats ont été assemblés et analysés pour identifier à la fois les goulets d’étranglement et les composants avec trop de ressources dans le système. Ces informations ont permis d’identifier les composants du système qui devaient être augmentés, réduits ou retirés avant la répétition d’autres tests.

Des tests manuels de l’expérience utilisateur ont été menés en capturant des enregistrements d’écran des testeurs de processus pour s’assurer que les utilisateurs du système peuvent réaliser leurs processus de manière productive.

Pour plus d’informations, consultez la section Concevoir une stratégie de test efficace.

Rythme des processus

Cette étude test a appliqué un modèle de rythme aux processus testés. Le modèle de rythme montre comment le test vise à simuler la cadence de travail d’un service, où les processus sont exécutés sous la forme d’un certain nombre d’opérations par heure au sein d’une équipe de ressources humaines. Cette approche était basée sur les commentaires des clients Esri et visait à concorder avec le scénario des clients d’une compagnie d’électricité de petite à moyenne taille sur laquelle reposaient les données.

Pendant la période de test d’une heure, les processus ont été répartis et échelonnés pour éviter des démarrages simultanés, tout en permettant un certain chevauchement – reproduisant ainsi la manière dont les tâches se déroulent en conditions réelles. Dans le modèle de rythme ci-dessous, vous pouvez voir comment nous avons spécifié le rythme et le nombre d’opérations par heure de chaque processus, ce qui définit la « charge de conception » du système. Cette charge est censée représenter l’activité d’une organisation dotée de 15 éditeurs ArcGIS Pro et de 200 utilisateurs Web ArcGIS. Cependant, la charge de conception est en réalité déterminée par le nombre d’opérations exécutées par heure.

La charge a ensuite été augmentée en multipliant les processus à un point tel que le système n’était plus en mesure de fournir des réponses acceptables ou de prendre en charge les processus. Notez que le modèle de rythme des processus appliqué dans cette étude test peut être différent de l’usage quotidien classique de votre organisation.

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

Cette architecture a été validée avec des tests de charge automatisés et des utilisateurs manuels dans quatre scénarios. Les résultats de chacun sont présentés ci-dessous. De manière générale, les résultats des tests montrent que, tel qu’il est implémenté, le système dispose de ressources suffisantes pour supporter des charges allant de la charge de conception à 8 fois la charge de conception. Les tests ont également réaffirmé l’importance d’une application et d’une configuration système appropriées pour les performances. Dans chaque scénario, l’utilisation du système augmente proportionnellement à la charge.

Scénario de test : charge de conception

• Le système a pris en charge la charge avec une faible utilisation globale des ressources

• ArcGIS Data Store (relationnel) n’a pas été utilisé : le fond de carte a été consulté en tant que service de tuiles vectorielles

Scénario de test : charge de conception x4

• Le système a pris en charge la charge
• Les serveurs d’hébergement s’exécutaient généralement à une capacité inférieure à 10 % du processeur
• Les serveurs SIG s’exécutaient généralement à une capacité inférieure à 20 % du processeur
• L’utilisation du processeur PostgreSQL est restée inférieure à 20 %

Scénario de test : charge de conception x8

• Le système a pris en charge la charge
• Les serveurs d’hébergement s’exécutaient généralement à une capacité inférieure à 20 % du processeur
• Les serveurs SIG s’exécutaient généralement à une capacité inférieure à 35 % du processeur
• L’utilisation du processeur PostgreSQL est restée inférieure à 40 % avec quelques pics autour de 65 %

Expérience utilisateur : durée des processus réalisés

Pendant que le système était sous charge, la durée des processus réalisés a été capturée, telle qu’elle a été expérimentée par les utilisateurs. Cela représente le temps nécessaire pour effectuer toutes les étapes répertoriées dans les processus. La durée des processus réalisés est cohérente jusqu’à ce que le système soit surchargé à 10 fois la charge nominale.

Expérience utilisateur : durée des étapes des processus réalisés

Pendant que le système était sous charge, la durée des processus réalisés des étapes clés des huit charges de travail a été capturée. Cela représente le temps moyen nécessaire pour effectuer une étape donnée.