Résultats des tests

Après les tests préliminaires, des tests plus formels ont été effectués pour évaluer l’architecture et la configuration modifiées avec les processus de base et mobiles. L’architecture modifiée a été testée en ajoutant des processus mobiles à différentes charges, avec des processus de bureau et de mise à jour s’exécutant de manière stable à une charge de conception 4x. Chaque composant a été surveillé pendant l’exécution des processus sur différents scénarios de charge. Vous pouvez comparer les impacts sur l’utilisation des ressources dans l’architecture modifiée par rapport à l’architecture d’origine.

Une fois les tests terminés, les résultats ont été compilés et analysés pour confirmer que le système tel qu’il a été conçu offre une expérience positive à l’utilisateur final et lui permet de travailler efficacement.

Rythme des processus

Cette étude test a appliqué un modèle de rythme aux processus testés. Un 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 processus ont été échelonnés sur une période de test d’une heure, tout en se chevauchant comme le feraient des 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.

Pour ce test, les processus de mise à jour Web et de bureau ont été automatisés pour s’exécuter à quatre fois la charge de conception (4x), comme le montre la figure ci-dessous. En savoir plus sur les processus testés.

Les processus de base ont été exécutés selon un modèle de rythme destiné à imiter la façon dont les gens travaillent, ce qui rend le test plus réaliste. Dans ce modèle, les processus sont décalés de sorte qu’ils ne démarrent pas ou ne se terminent pas en même temps.

Les processus mobiles ont été exécutés alors que le système était sous la charge décrite ci-dessus. La charge de conception pour les processus mobiles est illustrée ci-dessous, avec un total de 405 opérations par heure. La charge mobile a ensuite été multipliée tout en maintenant une charge de bureau constante.

Ce modèle de rythme montre la charge générale s’exécutant à 4x avec les processus mobiles rythmés à la charge de conception. Le modèle s’ajuste à mesure que la charge appliquée aux processus mobiles augmente.

Le processus de vue déconnecté inclut un téléchargement et une synchronisation, ce qui a un impact sur ArcGIS Enterprise. Le processus de mise à jour déconnecté commence par un téléchargement et une synchronisation similaires, mais inclut également une deuxième synchronisation pour charger les modifications. Le travail effectué sur l’appareil mobile pour afficher ou mettre à jour les données n’a pas d’impact sur ArcGIS Enterprise.

Scénario de test : charge de conception 6x

Avec une charge de conception 6x dans l’architecture d’origine (à gauche), les adaptateurs Web ArcGIS sont extrêmement saturés et les machines Portal for ArcGIS affichent une utilisation très élevée du processeur (voir la figure 13). Comparez cela à l’architecture modifiée (à droite), où l’utilisation des ressources, en particulier au niveau d’ArcGIS Web Adaptor et du portail ArcGIS, chute sensiblement à des seuils plus optimaux. En outre, vous pouvez observer comment l’augmentation du nombre de processeurs virtuels dans l’architecture modifiée a contribué à réduire la restriction liée au débit réseau (gris) observée dans l’architecture d’origine, qui provoquait une temporisation des téléchargements.

Expérience utilisateur

Comme prévu, l’expérience utilisateur se dégrade avec l’augmentation de la charge. Cependant, les effets sont plus perceptibles avec des processus déconnectés, comme indiqué ci-dessous. Par exemple, le temps d’affichage d’une vue déconnectée, qui inclut l’étape de téléchargement, augmente de 44 % entre la charge de conception et 4x, et de 78 % entre 4x et 6x. La majeure partie de ce temps est consacrée au téléchargement de la zone hors connexion et à la synchronisation des données. Par conséquent, outre le dimensionnement des ressources, l’optimisation des zones hors connexion, la mise à disposition des travailleurs mobiles de connexions performantes et même l’échelonnement des téléchargements, peuvent contribuer à améliorer ces délais.

La durée des processus ArcGIS Pro est dégradée de 12 % en moyenne entre la charge de conception et 6x, ce qui signifie que les éditeurs perdent 58 minutes par jour à attendre le système. Entre la charge de conception et 4x, ce nombre est de 9 %, ce qui représente 43 minutes par jour.

Étant donné que les éditeurs maintiennent le réseau conforme à l’exécution que de nombreux employés utilisent pour travailler, il est important de fournir un environnement d’édition performant. Bien que l’ajout de la charge des processus mobiles n’ait pas eu d’impact mesurable sur le système avant 4x la charge de conception, l’expérience utilisateur indique que des réglages de configuration peuvent s’imposer lorsque les charges commencent à dépasser la charge de conception d’origine.

Les éléments suivants peuvent améliorer l’expérience utilisateur et entraîner un retour sur investissement accru :

• Équilibreurs de charge alternatifs
• Séparation des charges de travail supplémentaires
• Augmentation de la taille des instances
• Approche de déploiement mobile sécurisée Le document technique sur l’implémentation de la sécurité mobile pour ArcGIS contient des informations supplémentaires.