Tests préalables

Les tests préalables constituent une étape de notre traitement destinée à améliorer les résultats de nos tests formels. Les tests préalables sont l’occasion d’effectuer les opérations suivantes :

• Identifier les goulets d’étranglement du système qui pourraient entraver les performances et la facilité d’utilisation du système sous la pression de la charge
• Expérimenter différents paramètres et configurations de manière itérative
• Rationaliser le processus plus formel de test de charge

L’architecture physique initiale était presque identique à celle d’un système de gestion des informations réseau de base précédemment testé et configuré avec SAP HANA, avec seulement l’ajout d’un point de terminaison VPN client AWS pour permettre aux appareils mobiles de se connecter. Au cours des tests préalables, nous avons déterminé que le système ne prendrait pas en charge la charge prévue avec les charges de travail supplémentaires, illustrées ci-dessous. L’architecture a ensuite été ajustée de manière appropriée, comme décrit dans l’architecture physique. Vous pouvez voir les résultats finaux des tests après que ces modifications ont été apportées dans la section des résultats des tests.

Tests préalables à une charge de conception 4x

Le système a d’abord été testé avec des flux de travail de gestion des informations réseau de base s’exécutant sans flux de travail mobiles, comme illustré sur le côté gauche de la figure ci-dessous. À l’exception d’un pic dans ArcGIS Web Adaptor 02 au début du test consacré à l’installation des mises à jour de Windows Defender, l’utilisation des ressources est relativement faible.

Comparez cela avec le côté droit de la figure, qui illustre comment l’ajout de flux de travail mobiles au-dessus de la charge 4x entraîne une utilisation importante du processeur dans les instances ArcGIS Web Adaptor et Portal for ArcGIS. Les adaptateurs Web ArcGIS Adaptor sont saturés, ce qui entraîne un ralentissement ou une expiration du délai de traitement des demandes. Les quatre serveurs SIG et la base de données affichent également une utilisation plus élevée du processeur (orange) et du disque (or). Cela est dû à l’étape de téléchargement dans les flux de travail hors connexion, où la zone hors connexion de 2,66 Go est téléchargée par un grand nombre d’opérateurs de terrain.

Les requêtes ouvertes pour la charge de base seule présentée ci-dessous (à gauche) illustrent le système qui gère la charge. Il y a une petite accumulation de requêtes ouvertes au début du test qui se stabilise avec un maximum de 19 éditeurs et 11 utilisateurs dotés du rôle de consultation. Toutefois, lorsque la charge mobile supplémentaire est ajoutée (côté droit), les requêtes passent à 42 requêtes bureautiques (utilisateurs dotés du rôle de consultation et éditeurs) et 127 requêtes mobiles simultanées avant que les téléchargements ne soient terminés et que la charge ne diminue. Ce modèle indique un ralentissement lors de l’étape de téléchargement du test pendant que les utilisateurs attendent la fin du téléchargement de la zone hors connexion.

Tailles d’instance

Au cours des tests préalables, nous avons observé de longs temps de téléchargement pour les zones hors connexion (2,66 Go), qui étaient supérieurs à 30 minutes (voir la figure ci-dessous). Après un dépannage, nous avons déterminé que le problème provenait d’une utilisation très élevée du processeur sur les instances d’ArcGIS Web Adaptor et de Portal for ArcGIS, qui limitait le débit et entraînait l’expiration des téléchargements. Pour résoudre ce problème, les instances d’ArcGIS Web Adaptor sont passées de 2 à 8 processeurs virtuels et les instances de Portal for ArcGIS de 4 à 8 processeurs virtuels.

L’étape de téléchargement des flux de travail déconnectés a en particulier bénéficié de l’augmentation de la taille des instances d’ArcGIS Web Adaptor et de Portal for ArcGIS, avec une réduction du temps de téléchargement de 41 %. Cependant, il s’agit d’une capacité excédentaire lorsqu’un grand nombre de téléchargements ne sont pas en cours. Dans un environnement de production, nous chercherions un moyen de faire évoluer ces composants pendant les périodes de pointe et de réduire la taille des instances lorsque cela n’est pas nécessaire pour réduire les coûts. Par conséquent, il est crucial d’optimiser vos ressources tout en équilibrant la taille des cartes hors connexion (en les rendant aussi petites que possible tout en couvrant la zone nécessaire) pour obtenir le bon équilibre entre performances et coûts.

• En savoir plus sur les pratiques conseillées pour utiliser les cartes hors connexion.

Configuration de l’instance de service

Dans ArcGIS Enterprise, les instances d’un service publié sont appelées processus ArcSOC. Il existe différentes façons de configurer les ArcSOC pour éviter les longs temps d’attente et une mauvaise expérience utilisateur. En général, si le nombre d’ArcSOC occupés dépasse le maximum affecté à un service, les temps d’attente augmenteront jusqu’à ce qu’un ArcSOC soit disponible. Toutefois, si le nombre maximal d’ArcSOC sur l’ensemble des services est supérieur au nombre de processeurs virtuels disponibles, les temps d’attente augmentent également à mesure que tous les processeurs virtuels sont occupés. Par conséquent, il est important de surveiller et de gérer le rapport entre les ArcSOC et les processeurs virtuels disponibles, en particulier lorsque des modifications du système sont introduites.

Avec 16 processeurs virtuels disponibles sur les deux serveurs d’hébergement, les paramètres d’instance de service initiaux pour le service de réseau de distribution mobile et le service de réseau de distribution de gaz en lecture seule ont chacun été définis comme suit :

• Minimum : 8
• Maximum : 8

Étant donné que le service de réseau de distribution de gaz en lecture seule a fonctionné à l’utilisation maximale d’ArcSOC pendant la majeure partie des tests préalables, alors que le service mobile disposait d’un excès d’ArcSOC libres, nous avons appris qu’une certaine reconfiguration du service était nécessaire. Consultez les figures ci-dessous pour une comparaison de l’utilisation d’ArcSOC avant et après l’optimisation.

Le nombre d’instances de service pour le service de réseau de distribution mobile a été réduit, passant d’un minimum et d’un maximum de 8 à un minimum et un maximum de 6. Le nombre d’instances de service pour le réseau de distribution de gaz a été augmenté, passant d’un minimum et d’un maximum de 8 à un minimum et un maximum de 10. Après la modification, les diagrammes montrent une distribution plus uniforme entre les deux services, alors que les temps d’attente des utilisateurs ont été sensiblement améliorés.

• En savoir plus sur l’optimisation et la configuration des services
• En savoir plus sur la configuration des paramètres des instances du service

Résultats des tests préalables

Les tests préalables du système de gestion des informations réseau de base d’origine avec les charges de travail mobiles ajoutées a permis d’identifier et de corriger les goulets d’étranglement et les erreurs de configuration du système, qui auraient autrement eu un impact négatif sur les performances du système et l’expérience de l’utilisateur final dans un environnement de production. Nos tests préalables ont permis d’apporter les ajustements suivants au système avant d’effectuer les tests formels :

• Les instances d’ArcGIS Web Adaptor ont été redimensionnées (de 2 à 8 processeurs virtuels).
• Les instances de Portal for ArcGIS ont été redimensionnées (de 4 à 8 processeurs virtuels).
• La taille des zones hors connexion a été optimisée pour les rendre aussi petites que possible tout en couvrant la zone nécessaire.
• La configuration ArcSOC a été ajustée pour assurer une distribution plus uniforme de l’utilisation et réduire les temps d’attente entre le service de réseau de distribution mobile et le service de réseau de distribution de gaz.