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’objectif était de vérifier que le système prenait en charge les processus et de comprendre l’impact de la charge sur le système, ses composants et 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 simule la cadence de travail dans une organisation de gestion des parcelles, où les processus sont exécutés selon un volume d’opérations par heure défini au sein d’une équipe de ressources humaines. Cette approche s’est appuyée sur les retours des clients d’Esri et visait à reproduire un scénario de client de gestion parcellaire de taille moyenne, cohérent avec les données utilisé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.

La charge a ensuite été augmentée en multipliant les processus jusqu’à un point où le système n’était plus en mesure de fournir des réponses acceptables ni de prendre en charge l’exécution correcte des processus — ou, dans le cas présent, jusqu’à un niveau suffisant pour valider que le système fonctionnerait pour le type d’organisation visé. 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 à 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.

Scénario de test : charge de conception

Observations:

• Le système a pris en charge la charge
• Les serveurs d’hébergement (processus de consultation) affichaient en moyenne une utilisation du processeur inférieure à 30 % (lignes orange)
• Les serveurs de parcelles (processus de mise à jour) affichaient en moyenne une utilisation du CPU inférieure à 40 %
• SQL Server affiche une très faible utilisation du processeur, restant en général en dessous de 15 %
• Le pic d’utilisation du disque sur l’instance SQL Server peut être attribué à un processus Windows en arrière-plan (lignes dorées)
• Les requêtes simultanées montrent que le système prenait en charge, à tout moment sur la période de test, environ 3 requêtes simultanées de consultation (rouges) et 1 requête simultanée de mise à jour (bleue).

Scénario de test : charge de conception x4

Observations:

• Le système a géré la charge, avec des augmentations marginales de l’utilisation des ressources sur l’ensemble des composants
• Les serveurs d’hébergement affichaient généralement une utilisation moyenne du processeur inférieure à 40 %
• Les serveurs de parcelles affichaient généralement une utilisation moyenne du processeur inférieure à 50 %
• SQL Server est généralement resté sous les 40 % d’utilisation du processeur
• Les pics périodiques d’utilisation du disque peuvent être attribués au démarrage des processus ou à des étapes spécifiques de processus. Plus précisément, le pic observé entre 15:10 et 15:20 est associé au processus Summarize Parcels (Synthétiser les parcelles), au cours duquel plusieurs tableaux de bord s’ouvrent simultanément
• Les requêtes simultanées montrent que le système prenait en charge en moyenne 10 à 15 requêtes simultanées (consultation et mise à jour) pendant toute la période de test, avec des pics plus élevés de requêtes de consultation simultanées, qui se résorbent très rapidement.

Scénario de test : charge de conception x8

Observations:

• Le système supporte la charge, avec une augmentation attendue de l’utilisation des ressources entre les composants
• Les serveurs d’hébergement restent généralement sous les 50 % d’utilisation du processeur
• Les serveurs de parcelles restent généralement sous les 50 % d’utilisation du processeur
• SQL Server présente des hausses significatives de l’utilisation des ressources, atteignant régulièrement environ 60 % d’utilisation du processeur.
• Les requêtes simultanées montrent que le système prenait en charge de façon régulière des pics de 35 requêtes de consultation simultanées et, sur l’ensemble de la période de test, une moyenne de deux requêtes de mise à jour simultanées.
• Le pic de requêtes de lecture à 20:20 correspond au démarrage du processus Summarize Parcels (Synthétiser les parcelles).

Configuration de l’instance de service

En plus de l’utilisation des ressources de machines virtuelles, nous avons également surveillé l’utilisation des ArcSOC à chaque exécution test, afin de déterminer si nos services étaient correctement paramétrés. Pour toutes les exécutions jusqu’à la charge de conception x8, les ArcSOC occupés sont restés bien en dessous du maximum (16), ce qui indique que nous avions configuré plus d’instances de carte que nécessaire pour ces charges. S’il s’agissait d’un environnement de production avec des charges inférieures à notre charge de dimensionnement ×8, nous pourrions choisir de réduire la taille des machines de serveur d’hébergement et de serveur SIG afin de diminuer les coûts. Cela supposerait de surveiller l’utilisation des ArcSOC ainsi que le processeur et la mémoire serveur afin de déterminer à quel moment une mise à l’échelle est nécessaire pour répondre à la demande. De plus, il faudrait s’assurer de ne pas surcharger ces machines, car chaque ArcSOC utilise une certaine quantité de mémoire et chaque ArcSOC occupé utilise un processeur virtuel.

Comme le montre le diagramme ci-dessous, les 16 ArcSOC sont tous occupés à certains moments sur le site du serveur d’hébergement, à la charge de dimensionnement x8. Lorsque tous les ArcSOC sont occupés, il faut s’attendre à une augmentation des temps d’attente des services (comme nous l’avons observé). Cependant, le serveur des parcelles (à droite) affiche une utilisation inférieure d’ArcSOC, avec seulement 9 utilisés au maximum sur les 16 configurés.

Le pic initial sur le serveur d’hébergement (à gauche) a été causé par le démarrage des tableaux de bord en début de test. Nous avons corrigé le rythme des processus pour les exécutions test suivantes, en espaçant les démarrages de tableaux de bord de plusieurs minutes pour mieux refléter les scénarios réels.

• Pour en savoir plus, consultez ce billet de blog qui explique l’art et la science de l’optimisation des ArcSOC.

Expérience utilisateur : durées des processus manuels

En plus des processus automatisés, nous avons également observé l’expérience utilisateur en capturant des enregistrements d’écran des testeurs de processus. De ces enregistrements, nous avons extrait des durées d’exécution des processus (c’est-à-dire le temps nécessaire pour effectuer toutes les étapes d’un processus). Cette pratique vise à s’assurer que les utilisateurs du système peuvent exécuter leurs processus de manière productive.

Comme le montre le graphique ci-dessous, les durées d’exécution des processus sont globalement cohérentes, avec seulement de faibles variations entre l’ensemble des scénarios de test. Cela indique que le système peut absorber la charge accrue sans dégrader la réactivité perçue par les utilisateurs finaux.

Expérience utilisateur : durée des étapes des processus manuels

En plus des processus eux-mêmes, nous avons également capturé la durée des étapes clés de tous les processus. Cela correspond au temps moyen qu’il a fallu pour exécuter une étape donnée de chaque processus lorsque le système était sous charge. Comme le montre le graphique ci-dessous, voici un exemple relatif au processus de fusion des parcelles (Merge parcels) : le temps nécessaire pour exécuter chaque étape est resté très stable d’un scénario de charge à l’autre. À quelques variations près, ce schéma se retrouve dans l’ensemble des processus.

Conclusions et points clés

Ces tests ont été réalisés dans un environnement de test, et non dans un système de production. Il est probable que votre système présentera des différences, que ce soit au niveau des processus, de la configuration ou de la conception. Par exemple, dans Azure, le Web Adaptor n’est généralement pas utilisé (si SAML est employé) et l’AppGateway répartit la charge directement vers les serveurs. Cependant, vous pouvez tirer des enseignements de ces approches et résultats de test pour vos propres besoins :

• Concevoir le système en intégrant l’observabilité de bout en bout fournit des informations précieuses pour ajuster correctement les performances au regard des coûts d’infrastructure, tout en permettant d’autres activités essentielles, comme le dépannage.
• Surveillez les ressources serveur de vos systèmes, l’utilisation des ArcSOC et les temps d’exécution des processus — à la fois pendant les tests (dans un environnement de préproduction/test) et en production.
• Identifiez les éventuelles inadéquations entre les ressources et leur utilisation. Par exemple :
  • À 8× notre charge de conception, le site du serveur d’hébergement semble correctement dimensionné pour ce volume de requêtes. Cependant, les serveurs SIG (serveurs de parcelles) ont encore un grand nombre de ressources non utilisées.
  • Il est possible de réduire l’échelle de notre infrastructure de plusieurs manières afin de diminuer les coûts, tout en préservant les performances et l’expérience utilisateur.
  • Il est également possible de reconfigurer nos ArcSOC afin de les répartir de manière plus optimale pour la prise en charge de nos processus.