Performance : Défis et Stratégies
ArcGIS Enterprise fournit une plateforme robuste et évolutive pour la fourniture de ressources SIG aux utilisateurs via des services et des applications web. Cependant, parfois, les déploiements peuvent rencontrer des performances lentes depuis les points de terminaison des ressources publiées.
Comme ArcGIS est très polyvalent, il peut y avoir différentes manières, configurations et options pour rendre ces ressources disponibles à la consommation.
Obtenir de bonnes performances n'est pas toujours aussi simple et direct que de simplement activer un paramètre "fast = true".
Ce qui pourrait être une fonctionnalité pratique pour certains administrateurs pourrait être une configuration qui, bien qu'utile, peut interférer avec les performances pour d'autres.
Dans le monde réel, la performance est souvent une fonction de plusieurs éléments et paramètres de configuration. Avoir des stratégies pour comprendre et surmonter les plus courants peut aider à mettre le déploiement sur la voie d'une performance plus rapide.
Qu'est-ce que la Performance ?
La performance est une description de la rapidité (ou lenteur) avec laquelle un serveur ou un service fonctionne pour une fonction particulière d'intérêt. Le temps qu'il faut à un service ArcGIS Server pour compléter une opération comme query, applyEdit ou export et ensuite renvoyer la réponse au client qui l'a demandée serait un exemple de performance.
Cette durée est mesurée en secondes ou millisecondes et est communément appelée temps de réponse.
Bien que appelé "temps de réponse", plusieurs étapes importantes composent le temps total qu'un client comme un navigateur web ou ArcGIS Pro passe à attendre une ressource serveur demandée :
- Recherche DNS du nom d'hôte du serveur
- Négociation SSL entre le client et le serveur
- Connexion TCP/IP entre le client et le serveur
- Envoi de la requête au serveur
- Traitement de la requête par le serveur
- Réception de la réponse du serveur
- Pour les réponses volumineuses, le Time-to-first-byte (ou TTFB) peut être utilisé à la place pour mesurer le temps de réponse
Typiquement, la majeure partie du temps est passée à l'étape 4.1. C'est là que le serveur travaille sur la réponse.
Cet article communautaire explorera les domaines pouvant impacter cette portion du temps de réponse.
Pourquoi la Performance est-elle Importante ?
Simplement : plus la performance est rapide, plus le temps de réponse est faible.
Plus le temps de réponse est faible, plus le serveur peut supporter de requêtes simultanément.
Cette plus grande concurrence des requêtes se traduit par une meilleure évolutivité ce qui signifie en fin de compte soutien pour plus d'utilisateurs.
La performance est mesurée comme une unité de temps nécessaire pour compléter une seule opération à la fois (par exemple, 0,238 secondes pour exécuter une requête feature).
L'évolutivité, quant à elle, est fréquemment mesurée en transactions ou opérations par unité de temps (par exemple, requêtes/sec ou opérations/heure).
Quand on parle d'obtenir une meilleure, plus rapide ou "plus" grande performance, cela implique d'atteindre des temps de réponse plus bas. D'autre part, une meilleure évolutivité implique d'atteindre un débit plus élevé (par exemple, plus d'opérations/heure).
Note : Bien sûr, pour obtenir une meilleure performance ou un meilleur débit, les opérations d'intérêt doivent s'exécuter correctement et répondre avec le contenu attendu (par exemple, image cartographique, données json ou pbf). Les messages d'erreur, par exemple, peuvent être une réponse rapide et simple dont la livraison peut atteindre un taux élevé de débit. En tant que testeurs et analystes, ce type de débit n'est pas ce que nous recherchons... nous sommes intéressés par le débit des requêtes réussies.
Quelle est une Performance Acceptable ?
Cela dépend.
Les critères ou exigences pour classer un élément comme ayant une performance rapide (ou lente) peuvent varier grandement selon l'organisation, les services publiés et les opérations attendues que les utilisateurs appelleront.
Il n'est pas rare d'avoir différents objectifs de temps de réponse pour les fonctions ArcGIS Server ou les flux de travail des applications utilisateur (plusieurs requêtes regroupées représentant une opération).
N'importe quel nombre de secondes peut convenir comme exigence mais gardez à l'esprit qu'il peut nécessiter plus de matériel ainsi qu'un réglage et des stratégies plus étendus (cet article) pour atteindre des objectifs agressifs.
Comment la Performance est-elle Mesurée ?
Le temps de réponse est la métrique clé pour déterminer si la performance répond ou reste dans ou sous une exigence cible.
Les stratégies courantes pour mesurer sont :
- Interaction utilisateur unique
- Via le navigateur web ou ArcGIS Pro
- C'est l'endroit le plus facile pour commencer
- S'il n'y a pas encore de compréhension sur la performance, commencez ici
- Analyse statistique d'un grand volume de temps de réponse
- Via des outils d'analyse des logs, la page Statistiques du gestionnaire ArcGIS Server ou d'autres utilitaires d'observabilité
- Ces approches ont l'avantage d'analyser des requêtes réelles que les utilisateurs ont déjà exécutées contre le déploiement
- Ceci est discuté plus en détail plus loin dans l'article
- Tests de charge
- Peuvent fournir une compréhension sur la performance et l'évolutivité
- Mise en place plus chronophage
- Des ressources en ligne existent pour commencer
Lorsque vous analysez les logs ou effectuez des tests, une stratégie courante consiste à exploiter les statistiques pour décomposer un grand nombre de temps de réponse. La moyenne et le 90e (ou 95e) percentile, le minimum et le maximum aident à fournir une compréhension des performances que l'utilisateur a pu expérimenter.
Capture des Temps de Réponse -- Navigateur Web
Comment les temps de réponse sont capturés via l'interaction utilisateur unique est un sujet intéressant.
L'approche la plus simple pour capturer les temps de réponse des requêtes REST depuis une application web est avec la fonctionnalité "outils développeur" du navigateur. Tous les navigateurs majeurs offrent une vue des requêtes, réponses et temps envoyés et reçus. Cette durée peut donner une idée de la rapidité avec laquelle une requête ou opération (potentiellement plusieurs requêtes) a été effectuée. Des décisions peuvent alors être prises si cela est acceptable ou doit être amélioré.
Capture des Temps de Réponse -- ArcGIS Pro
Tandis qu'ArcGIS Pro communique également avec ArcGIS Enterprise via REST, il ne possède pas d'équivalent intégré aux outils développeur. Pour capturer les temps de réponse, vous aurez besoin d'un débogueur HTTP séparé. Il en existe beaucoup ; un choix populaire est Fiddler.
Avec Fiddler installé sur la même machine qu'ArcGIS Pro, il peut être configuré pour intercepter le trafic. Les paramètres des requêtes, contenu des réponses et temps peuvent être capturés et examinés de manière similaire.
Des Objectifs Sont-ils Nécessaires pour Améliorer la Performance ?
Absolument pas. Les administrateurs SIG peuvent toujours analyser, optimiser et appliquer les meilleures pratiques au système même s'il n'y a pas d'exigences officielles en matière de performance.
Cependant, il est fortement recommandé de comprendre quelle performance votre système délivre initialement (par exemple, ce sont typiquement appelés chiffres baselines du temps de réponse) avant que des ajustements soient faits. Ainsi vous pouvez déterminer si les changements appliqués ont un effet positif.
Défis Courants en Matière de Performance et Stratégies Potentielles
Types et Instances du Pool de Services
< DIV >< P >< SPAN > L'un des domaines les plus fréquents où les administrateurs ArcGIS rencontrent des défis en matière de performance est le réglage du nombre approprié d'instances pour les services
dédiés. Mais d'abord, passons en revue les différents types.
Il y a 3 types de services, chacun avec ses propres forces. </ P ></ DIV >< UL >< LI >< STRONG >Dédié </ STRONG ></ LI >< LI >< STRONG >Hosted </ STRONG ></ LI >< LI >< STRONG >Shared </ STRONG ></ LI ></ UL >< DIV >< P >En tant qu'administrateur SIG il est important d'être capable d'identifier le type d'instance pour un service.<\/P> Cela peut être facilement consulté dans ArcGIS Server Manager, sous Gérer les services :<\/DIV>
<\/DIV>
<\/span><\/P><\/DIV>Sélection du type approprié<\/SPAN><\/H3>Choisir un type de service dédié est idéal lorsque l'on souhaite obtenir le meilleur contrôle des performances et de la scalabilité<\/U>. Avec ce type, l'administrateur peut :<\/P><\/DIV>Définir le nombre maximum d'instances au nombre de cœurs CPU pour tirer pleinement parti de la capacité de traitement disponible sur la machine ArcGIS Server (via le maximum)<\/SPAN><\/LI>Conserver la mémoire lorsqu'elle est inactive (via le minimum)<\/SPAN><\/LI>Ajuster pour une performance prévisible en définissant le min et le max à la même valeur<\/SPAN><\/LI><\/UL>Les services dédiés sont idéaux pour les services très sollicités ou ceux où la performance est primordiale.<\/P>Les services hébergés n'utilisent pas d'instances ArcSOC et s'adaptent automatiquement selon les besoins. Cependant, les capacités ArcGIS disponibles pour eux (Hosted) sont limitées car ils sont principalement utilisés avec des requêtes de fonctionnalités.<\/P>Les services partagés sont excellents pour accéder à des éléments demandés moins fréquemment. Ils disposent généralement de plus de capacités ArcGIS mais pas toutes les fonctionnalités ArcGIS sont disponibles (par exemple, la version branchée). Un pool d'instances partagées est le type par défaut lors de la publication d'un service avec ArcGIS Pro<\/U>.<\/P>Note : Il est important de rappeler que si le type de service sélectionné est dédié, le nombre (minimum et maximum) d'instances doit être évalué pour s'assurer qu'il est optimal. La valeur par défaut lors de la publication dans ArcGIS Pro est d'utiliser un maximum de seulement 2 (instances). Cela peut être trop faible et inadéquat pour les services où la performance/scalabilité sont importantes.<\/STRONG><\/FONT> <\/SPAN><\/P><\/DIV>Concentrez la carte<\/H2>L'optimisation de la carte n'est pas une nouvelle stratégie mais une méthode relativement simple à suivre pour obtenir de meilleures performances de votre déploiement.
Lorsque la carte est concentrée sur son objectif principal et sa présentation, le système n'a pas à effectuer un travail inutile. Rappelez-vous, le web est une plateforme multi-utilisateurs. Rendre l'affichage des données dynamiques aussi fluide que possible est la clé d'une bonne performance (et scalabilité). Avec potentiellement de nombreuses requêtes se produisant en même temps, le contenu partagé doit être aussi efficace que possible.<\/P>
<\/span>Stratégies cartographiques<\/SPAN><\/H3>Choisir une étendue par défaut optimale<\/SPAN>Si la carte fournit des données sur Los Angeles, l'étendue par défaut ne doit pas<\/EM> montrer toute la Californie<\/LI>Si plusieurs échelles cartographiques différentes sont nécessaires, utilisez les dépendances d'échelle et la généralisation pour limiter le détail à quand vous en avez le plus besoin (par exemple, aux plus grandes échelles)<\/LI><\/UL><\/LI>Supprimer les couches inutilesEnvisagez de supprimer les couches de données agréables à avoirAu minimum, désélectionnez-les et laissez l'utilisateur choisir de les activer<\/LI><\/UL><\/LI><\/UL><\/LI>Limiter volontairement ce que les utilisateurs peuvent faire avec un service<\/LI>Éviter la reprojection à la voléeUtiliser le même système de coordonnées pour le cadre de données et les données<\/LI><\/UL><\/LI>Requêtes de définitionS'assurer que des index sont en place si une logique de comparaison est appliquée aux colonnes d'attributs <\/LI><\/UL><\/LI><\/UL>Note : "Concentrer la carte" s'applique aux cartes, applications et services<\/FONT><\/STRONG><\/DIV>Versions logicielles<\/H2>Une version particulière d'ArcGIS Enterprise (et ses solutions associées) peut avoir plusieurs correctifs après sa sortie initiale. Ces correctifs peuvent offrir des améliorations de performance ainsi que des corrections fonctionnelles et de sécurité. <\/P>Il est fortement recommandé de vérifier périodiquement le site Esri Patches and Updates<\/A> ou d'exécuter l'outil "Check for ArcGIS Enterprise Updates". Ensuite, appliquez les mises à jour au moment approprié.<\/P>
Contention des ressources et expansion<\/H2>Il y a des moments où les meilleures pratiques et stratégies pour la performance sont appliquées mais où des temps de réponse plus faibles et une scalabilité plus élevée sont encore nécessaires. Peut-être que le matériel actuel exécutant ArcGIS Server est simplement épuisé où la puissance de traitement ou la mémoire sont devenues le goulot d'étranglement pour améliorer l'expérience utilisateur.<\/P>Pour ces situations, vous devez envisager une expansion et/ou une mise à niveau du matériel.<\/DIV>
Scalabilité<\/SPAN>
Pour les niveaux ArcGIS Server et ArcGIS Web Adaptor du déploiement, vous généralement< \/STRONG > < \/EM > avez les options suivantes pour améliorer la scalabilité< \/EM > en utilisant du matériel : < \/SPAN >< \/DIV >Montée en charge verticale< \/STRONG >Ajouter plus de ressources à la machine existante (par exemple, des cœurs supplémentaires)< \/SPAN >Une mémoire supplémentaire peut également aider à monter en charge en permettant au déploiement d'avoir plus d'instances ArcSOC fonctionnant simultanément< \/SPAN > < \/SPAN >< \/LI >< \/UL >< \/LI >Idéal pour des déploiements tels que : cloud, virtualisation, Kubernetes< \/SPAN >< \/LI >< \/UL >< \/LI >Montée en charge horizontale< \/STRONG >Ajouter plus de machines avec une capacité équivalente en ressources< \/SPAN >< \/LI >Idéal pour des déploiements tels que : sur site, cloud, virtualisation, Kubernetes< \/SPAN >< \/LI >< \/UL >< \/LI >< \/UL >Performance< \/SPAN >Pour améliorer la performance< \/EM > avec du matériel, il y a généralement une seule option :< \/SPAN >Obtenir des cœurs de traitement plus rapides< \/STRONG > Idéal pour des déploiements tels que : cloud, Kubernetes< \/SPAN >< \/LI >< \/UL >< \/LI >< \/UL >La configuration du paging du système peut également impacter la scalabilité même lorsque des ressources mémoire suffisantes ont été ajoutées au système. Bien qu'il s'agisse d'un paramètre logiciel du système d'exploitation et non du matériel, il peut jouer un rôle crucial dans l'exécution de nombreuses instances ArcSOC simultanées. Assurez-vous de configurer cela en conséquence pour gérer une charge avec beaucoup d'instances ou des instances avec une grande empreinte mémoire.< \/FONT >Il peut y avoir des situations où la performance est limitée et semble être liée au CPU (par exemple, un goulot d'étranglement dû à une puissance de traitement limitée). Une inspection plus approfondie peut révéler que le "coupable" est une ou plusieurs requêtes lentes qui étaient sous-optimales dès le départ ou une opération coûteuse appelée trop fréquemment (via des tâches administratives périodiques). Dans ce cas, il peut être plus efficace d'adresser ces requêtes "mauvaises" pour améliorer la performance et la scalabilité.< \/FONT >Note : Ces stratégies d'expansion visent à surmonter les limitations générales de traitement< \/EM > et mémoire. Mais, les ressources disque et réseau (bande passante, latence) peuvent aussi être des goulots d'étranglement. Pour certains environnements, ceux-ci peuvent être plus compliqués à étendre nécessitant des étapes supplémentaires pour leur mise à niveau.< \/STRONG >Une approche générale pour scaler<\ /FONT >
Pour ArcGIS Server il peut être plus facile d'abord monter en charge verticalement puis horizontalement. La raison vient de la configuration du Site et des répertoires qui devraient être migrés vers un stockage partagé si l'architecture passe d'une machine unique à un déploiement multi-machines.<\ /DIV > <\ /DIV > <\ /DIV > Combien devriez-vous monter en charge... deux serveurs, cinq serveurs ? Sans détails sur les temps moyens de réponse et le nombre anticipé d'utilisateurs à supporter, il est difficile de fournir une réponse concise.<\ /P > Cependant, une approche simpliste, générale <\ /EM > serait simplement d'essayer doubler la quantité actuelle (mémoire et/ou cœurs physiques) et observer l'impact.<\ /P > Dans bien des cas, cela fonctionne probablement bien jusqu'à 16 CPUs. À ce stade, ajouter une autre machine peut être plus avantageux.<\ /P > <\ /DIV > <\ /DIV > Note : Votre licence produit actuelle peut impacter combien de cœurs physiques vous pouvez utiliser avec ArcGIS Server. Vérifiez auprès de votre gestionnaire de compte Esri pour plus de détails.<\ /STRONG > <\ /DIV >
Note : Pour un support concernant la planification de capacité ou la conception architecturale (ce qui peut aider à fournir une compréhension détaillée et une estimation des ressources matérielles requises pour un ensemble donné de workflows), contactez Todd Jarrard (tjarrard@esri.com) chez Esri Professional Services.<\ /STRONG > Observabilité
"Quantifier ArcGIS" est une excellente stratégie... un favori personnel. Elle définit quelles ressources étaient demandées et à quelle vitesse les réponses ont été fournies pour satisfaire ces demandes. C'est important pour obtenir une compréhension des performances générales du système. Si l'utilisation des ressources système peut également être capturée, l'analyse peut être encore améliorée.
Il existe de nombreux utilitaires disponibles pour examiner périodiquement votre système. Certains outils peuvent lire les journaux d'accès et se concentrer principalement sur la performance statistique des requêtes effectuées par les utilisateurs. D'autres peuvent interroger la page des statistiques du Server et capturer l'utilisation du CPU (d'ArcGIS Server ou de la base de données) pendant cette période. Quelle approche est la meilleure ? Si l'observabilité n'a pas encore lieu, alors très probablement, n'importe laquelle d'entre elles serait un bon ajout. Elles aident toutes à fournir une certaine forme d'information sur la performance et la santé du déploiement.
Une fois l'analyse effectuée pour un déploiement, des rapports peuvent généralement être générés qui mettent en évidence quels services de carte pourraient être intéressants en raison de :
- Les temps de réponse observés étant plus lents que prévu
- Le nombre de requêtes émises pour la ressource
- À la fois le temps de réponse et le nombre de requêtes
Pour un Site ArcGIS avec de nombreux services, savoir lesquels sont statistiquement lents ou consomment le plus de ressources aide à concentrer les efforts d'optimisation. Avec de tels rapports, l'administrateur SIG a transformé les données en informations précieuses et est maintenant mieux informé pour prendre des décisions visant à améliorer l'expérience utilisateur. Cela dit, examiner les journaux et les statistiques n'est qu'une tranche (importante) du gâteau d'analyse.
Un défi avec les outils d'observabilité courants
De nombreux outils d'observabilité et de surveillance système concentrent l'analyse sur les requêtes et réponses des services. C'est une bonne approche et aide certainement les administrateurs à quantifier ArcGIS, mais elle peut avoir une limite. La limite peut apparaître avec l'hypothèse qu'un service de carte lent peut être "réparé" simplement en ajoutant des cœurs de traitement. Plus de cœurs pourraient améliorer certains aspects de la situation, mais il est recommandé que le service soit examiné (ou même réexaminé) plus en profondeur avant d'obtenir plus de ressources.
Cela revient à la section "Focus the Map", par exemple :
- S'assurer que les données pour le service ne sont pas affichées à des échelles trop petites
- Éviter les requêtes sous-optimales
Une analyse détaillée des requêtes peut aider à montrer la survenue de ces comportements qui pourraient être masqués par un rapport général du service. Cependant, bien que la décomposition des paramètres de requête du service et des requêtes sous-jacentes puisse améliorer l'analyse, elle peut ajouter de la complexité au rapport lui-même (par exemple, plus de temps d'exécution, plus de vues à examiner, la compréhension des vues). De plus, tous les outils d'observabilité ne réalisent pas ce type d'inspection.
Certaines initiatives récentes qui gagnent en popularité tentent de s'attaquer à ce problème. Elles sont basées sur une approche ascendante d'analyse où le point de départ est les requêtes sous-jacentes à la base de données elles-mêmes via un mécanisme connu sous le nom de "query datastore". L'analyse du query datastore est puissante et n'impacte pas la performance de la base comme un trace pourrait le faire mais elle nécessite une certaine connaissance des requêtes elles-mêmes et leur but. Attendez-vous à ce type de capacité d'analyse dans le futur pour tirer le meilleur parti de vos outils d'observabilité.
Conclusion
Il n'y a pas un seul élément facile à ajuster pour augmenter les performances et la scalabilité d'un Site ArcGIS Enterprise. Cependant, cet Article liste quelques stratégies communes qui peuvent être appliquées ensemble pour l'améliorer. Il est aussi important de comprendre que ce sont des éléments qui doivent être périodiquement revisités et pris en compte. Les habitudes des utilisateurs changent avec le temps tout comme la popularité d'une application web ou d'un service. Les ressources assignées à un service particulier peuvent être réévaluées ou réduites pour faire place au prochain élément mis en avant dans votre Site.
L'analyse des performances ArcGIS peut être amusante mais c'est aussi un effort continu pour maintenir la meilleure expérience utilisateur.
Attribution
Ressource : File:Grayson_running_the_4x100.jpg
Description : Anglais : Grayson courant le premier relais du 4x100 lors du Tigered invite 2010
Auteur : Graysonbay
Créé : 02:02, 29 novembre 2010
Licence : Ce fichier est sous licence Creative Commons Attribution 3.0 Unported license
Ressource : File:Kurvimeter_1_fcm.jpg
Auteur : Frank C. Müller, Baden-Baden
Licence : Ce fichier est sous licence Creative Commons Attribution-Share Alike 4.0 International license.
Ressource : File:My_Opera_Server.jpg
Description : Un serveur utilisé pour My Home
Auteur : William Viker, william.viker@gmail.com (c) 2006
Licence : Le détenteur du droit d'auteur de ce fichier permet à quiconque de l'utiliser à toute fin, à condition que le détenteur du droit soit correctement attribué. La redistribution, les œuvres dérivées, l'utilisation commerciale et toute autre utilisation sont permises.
Ressource : File:Samsung-1GB-DDR2-Laptop-RAM.jpg
Description : Une barrette mémoire DDR2 667 MHz (PC2-5300) d'un gigaoctet pour ordinateur portable, fabriquée par Samsung et retirée d'un MacBook 2007.
Auteur : Evan-Amos
Créé : 1 août 2018
Licence : Domaine public
