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 de gaz de petite à moyenne taille sur laquelle reposaient les données.

Les différents processus ont été répartis sur une période de test d’une heure et échelonnés de façon à ne pas commencer en même temps, tout en se chevauchant les uns avec les autres comme le feraient également les processus réels. Cette décomposition globale du rythme des processus est considérée comme la « charge de conception » à laquelle le système est soumis. 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 trois 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 à 4 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 cette charge
• Les serveurs d’hébergement s’exécutaient généralement à une capacité inférieure à 20 % d’utilisation du processeur
• Les serveurs SIG s’exécutaient généralement à une capacité inférieure à 20 % d’utilisation du processeur
• SQL Server s’exécutait généralement à une capacité inférieure à 20 % d’utilisation du processeur

Scénario de test : charge de conception x4

• Le système a pris en charge cette charge
• Les serveurs d’hébergement s’exécutaient généralement à une capacité inférieure à 40 % d’utilisation du processeur
• Les serveurs SIG s’exécutaient généralement à une capacité inférieure à 40 % du processeur, avec un pic d’utilisation de 50 à 60 %
• SQL Server s’exécutait généralement à une capacité inférieure à 50 % d’utilisation du processeur

Scénario de test : charge de conception x8

• Le système n’a pas pris en charge la charge
• Les serveurs d’hébergement ont atteint un pic à plus de 80 % d’utilisation du processeur
• Les serveurs SIG ont atteint un pic à plus de 80 % d’utilisation du processeur
• SQL Server a atteint un pic à plus de 90 % d’utilisation du processeur
• Le nombre d’utilisateurs simultanés performants a augmenté car les demandes n’ont pas pu être traitées en raison de la surcharge du système. Le système a commencé à renvoyer des erreurs dans les journaux et la télémétrie

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 était cohérente jusqu’à ce que le système soit surchargé à 8 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 de chaque étape clé des huit charges de travail a été capturée. Cela représente le temps moyen nécessaire pour effectuer une étape donnée. La durée est cohérente jusqu’à ce que le système soit surchargé à 8 fois la charge nominale.