Partagé<\/LI><\/UL>Note : Le temps d'attente est la durée pendant laquelle la requête reste dans une « file d'attente » sur le serveur jusqu'à ce qu'une instance ArcSOC soit disponible pour commencer à la traiter.<\/FONT><\/STRONG><\/P>Services du Pool d'Instances Dédiées<\/H1>Les services dédiés (par exemple, les services non hébergés et non partagés) sont une ressource essentielle d'ArcGIS dans les déploiements car de nombreuses applications dépendent des capacités telles que le géotraitement, l'édition Branch Version, et les flux de travail Utility Network (tous nécessitant des services dédiés).<\/P>Bien que ces services soient très polyvalents et constituent un pilier majeur dans ArcGIS en raison des fonctionnalités qu'ils fournissent, en tant qu'administrateur SIG, vous devez examiner, ajuster et configurer périodiquement le nombre d'instances ArcSOC (minimum et maximum) pour tirer pleinement parti de vos ressources disponibles à mesure que votre Site et vos utilisateurs grandissent.<\/P>
<\/span><\/P>Pour en savoir plus sur les instances ArcSOC, voir : <\/SPAN>Comprendre les instances de service<\/P>Limitations des Services du Pool d'Instances Partagées<\/H1>Les instances de service partagées sont excellentes ! Elles changent véritablement la donne pour aider les administrateurs à gérer la demande pour de nombreux services avec des ressources limitées. Cependant, leurs restrictions et exigences limitent les capacités de service pouvant être utilisées avec elles. Par exemple, le géotraitement, l'édition Branch Version, et Utility Network ne sont actuellement pas pris en charge via les services partagés (ni via les services hébergés). Cela laisse les services dédiés comme seul choix pour ces fonctionnalités.<\/P>Disponibilité Configurée des Instances ArcSOC vs Demande d'Instances<\/H1>Pour les services très populaires, critiques et/ou nécessitant de fonctionner sous le type de service dédié, comprendre le paramètre optimal des instances est important pour plusieurs raisons. Si le nombre maximum d'instances actives est trop élevé, la mémoire est gaspillée (ainsi que le coût). La surallocation des instances ArcSOC est un cas important mais unique car son impact ne se manifeste pas dans l'analyse uniquement des temps de réponse.<\/P>Inversement, avoir un maximum trop bas peut affecter la performance (sous forme de temps de réponse plus élevés et temps d'attente plus longs) car les utilisateurs pourraient attendre fréquemment qu'une instance ArcSOC déjà occupée se libère.<\/P>Bien sûr, définir le minimum et le maximum d'instances à des valeurs différentes a aussi un compromis. Pour les services critiques où la performance est primordiale, faire attendre la requête de l'utilisateur pendant qu'une instance doit être démarrée peut prendre du temps et affecter la performance. Ainsi, pour une performance prévisible sur les services essentiels, il est recommandé de définir le nombre minimum et maximum d'instances à la même valeur.<\/P>Comme indiqué sur Introduction aux instances de service :<\/P>Par conséquent, il est important pour les administrateurs d'ArcGIS Server de surveiller le nombre d'instances que leur site exécute, et de limiter les instances en cours lorsque la performance est inhibée par l'utilisation mémoire.<\/STRONG><\/FONT><\/P>Configurer la disponibilité du service (via ses minimums et maximums d'instances) ainsi que l'impact de ces réglages sur la demande utilisateur du service est clé pour un Site fonctionnant de manière optimale. Il existe une relation mutuelle entre configurer la disponibilité du service (via les minimums et maximums d'instances) et l'effet direct que cela a sur les requêtes arrivant à un service dédié. Bien que trouver le réglage optimal soit une tâche continue, il existe certains outils et ressources pour aider les administrateurs à relever ce défi.<\/P>Rapport de Service ArcGIS Server
<\/STRONG><\/H1>Le Rapport de Service d'ArcGIS Server (introduit en 10.1) est l'un de ces joyaux méconnus de l'API REST Admin. Cette ressource peut aider à surveiller un Site en fournissant un résumé configurable de tous les services dans un dossier. C'est généralement une requête rapide (selon le nombre de services dans le dossier demandé).<\/P>La section statistiques des instances du service dans la réponse retournée est extrêmement précieuse car elle liste les détails sur les instances ArcSOC (min, max, occupées) à travers tout le déploiement (par exemple, le Site ArcGIS Server).<\/P>En interrogeant périodiquement ce point final, on peut obtenir une vision instantanée de la configuration des instances du service par rapport à la demande... au moment même où elle se produit. Avec ces informations, on peut prendre de meilleures décisions pour optimiser les ressources machine et service. Cela peut à son tour aider à améliorer les temps de réponse et réduire les temps d'attente.<\/P>Note : Dans ArcGIS Server, les statistiques des instances du service et la page Statistiques dans Manager sont en réalité des ressources différentes bien qu'elles fournissent des vues similaires des mêmes données. Les statistiques du service donnent un accès brut aux valeurs des instances (à l'échelle du Site et par machine) ainsi que plus de détails. La page Statistiques est une interface pour créer des rapports à partir d'une partie de ces informations.
Automatisation de la Collecte du Rapport de Service avec Soccer<\/H1>N'importe quel script, programme ou outil qui observe régulièrement le point final Rapport de Service du dossier concerné conviendrait. Cependant, si vous cherchez un outil gratuit existant alors Soccer est recommandé.
(Arc)SOC ScannER ou Soccer est un utilitaire pour scanner et lire les statistiques des services sur un dossier spécifique d'ArcGIS Server. Il analyse les données collectées et écrit un fichier CSV pour une analyse postérieure supplémentaire (par exemple, créer des graphiques dans un tableur pour visualiser l'utilisation). Il exploite la ressource Rapport de Service REST Admin dans ArcGIS Server pour rassembler ces infos. L'objectif initial de soccer était de capturer la sortie du point final rapport d'un dossier spécifique dans ArcGIS Server et sauvegarder les statistiques des instances ArcSOC (par exemple Running, Busy, Maximum...) pour chaque service.
Actuellement, soccer est uniquement un utilitaire en ligne de commande. Il est disponible dans le runtime portable .NET 6.0 pour Windows (win-x64), Linux (linux-x64) et macOS (osx-x64).
Pour simplifier, exécuter soccer nécessite seulement 3 entrées (d'autres paramètres peuvent être passés pour étendre ses fonctionnalités) :
soccer.exe -s "[https:\/\ArcGISServer\ServerWebAdaptor]" -f [FolderToScan] -t "[PreGeneratedArcGISToken]"Par exemple :
soccer.exe -s "https://gisserver.domain.com/server" -f "Gas" -t "APLeyWOcKZp9stZ_C01DQ.."Note : Un jeton ArcGIS Server pré-généré peut être obtenu depuis Portal. Typiquement, l'URL generateToken est : https://gisserver.domain.com/portal/sharing/rest/generateToken et l'URL Webapp serait alors : https://gisserver.domain.com/server/admin. Définissez la valeur d'expiration à quelque chose d'approprié pour la durée de surveillance prévue.Sortie standard lors de l'exécution depuis une fenêtre de commande :Connecté à : "https://gisserver.domain.com/server " (Gas)Appuyez deux fois sur Ctrl-C pour arrêter...Pause de 5 secondes...Lors de l'exécution, soccer se connecte au point de terminaison Service Report du dossier ArcGIS Server spécifié, collecte les données, les écrit dans un fichier CSV local, puis se met en pause. Après la durée de pause écoulée, il répète le processus. Soccer continuera à collecter jusqu'à ce que le processus soit arrêté manuellement (Ctrl-C).Note : Pour collecter sur le dossier racine ArcGIS Server, utilisez soit : -f "/" ou -f ""Analyse du fichier CSV
Exemple de contenu vu depuis un simple visualiseur de texte :
DateTime,Epoch,IntervalSeconds,Host,Folder,ServiceName,Type,Provider,Running,Busy,Maximum,Free,NotCreated,Initializing,Transactions,TotalBusyTime,ServicesCollected,ResponseTimeMilliseconds,ContentLength,ConfiguredState,RealTimeState,Message
5/2/2023 1:12:45 AM,1682989965310,5,gisserver.domain.com,Gas,Gas_Utility_Network,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,121.6224,6065,STARTED,STARTED,succès
5/2/2023 1:12:45 AM,1682989965310,5,gisserver.domain.com,Gas,Landbase_PostgreSQL,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,121.6224,6065,STARTED,STARTED,succès
5/2/2023 1:12:50 AM,1682989970469,10,gisserver.domain.com,Gas,Gas_Utility_Network,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,117.901,6065,STARTED,STARTED,succès
5/2/2023 1:12:50 AM,1682989970469,10,gisserver.domain.com,Gas,Landbase_PostgreSQL,MapServer,ArcObjects11,32,0,32,32,0,0,0,0 ,2 ,117.901 ,6065 ,STARTED ,STARTED ,succès
5/2/2023 1:12:55 AM ,1682989975606 ,15 ,gisserver.domain.com ,Gas ,Gas_Utility_Network ,MapServer ,ArcObjects11 ,32 ,0 ,32 ,32 ,0 ,0 ,0 ,0 ,2 ,109.6187 ,6065 ,STARTED ,STARTED ,succès
5/2/2023 1:12:55 AM ,1682989975606 ,15 ,gisserver.domain.com ,Gas ,Landbase_PostgreSQL ,MapServer ,ArcObjects11 ,32 ,0 ,32 ,32 ,0 ,0 ,0 ,0 ,2 ,109.6187 ,6065 ,STARTED ,STARTED ,succès
5/2/2023 1:13:00 AM ,1682989980733 ,20 ,gisserver.domain.com ,Gas ,Gas_Utility_Network ,MapServer ,ArcObjects11 ,32 ,0 ,32 ,32 ,0 ,0 ,0 ,0 ,2 ,125.1686 ,6065 ,STARTED ,STARTED,succès
5/2/2023 1:13:00 AM ,1682989980733 ,20,gisserver.domain.com,G as,L andbase_PostgreSQL,M apServer,A rcObjects11,,32,,032,,320,,00,,00,,02,,125.1686,,6065,,STARTED,,STARTED,,succès
5/2/2023 1:13:05 AM,,1682989985874,,25,gisserver.domain.com,,Gas,,Gas_Utility_Network,,MapServer,,ArcObjects11,,32,,00,,320,,320,,00,,00,,02,,116.3949,,6065,,STARTED,,STARTED,succès
5/2/2023 1:13:05 AM ,,1682989985874 ,,25 ,,gisserver.domain.com ,,Gas ,,Landbase_PostgreSQL ,,MapServer ,,ArcObjects11 ,,32 ,,00 ,,320 ,,320 ,,00 ,,00 ,,02 ,,116.3949 ,,6065 ,,STARTED ,,STARTED ,,succès
Note : Par conception les colonnes telles que IntervalSeconds et ResponseTimeMilliseconds afficheront des valeurs dupliquées si plus d'un service existe dans le dossier observé.
Les données collectées sont un CSV typique mais il y a certains champs importants qui seront utiles pour analyser rapidement l'activité ArcSOC de notre(s) service(s) d'intérêt :
- IntervalSeconds
- ServiceName
- Running
- Busy
- Maximum
En ouvrant le fichier CSV dans un tableur électronique d'autres services résidant dans le même dossier peuvent être facilement filtrés via la colonne ServiceName. Les valeurs IntervalSeconds,Runnning,Busy et Maximum peuvent alors être tracées pour visualiser (par exemple via le graphique Scatter with Smooth Line) et montrer la configuration des instances par rapport à la demande entrante. Dans ce cas le service Gas_Utility_Network était configuré avec une instance min/max de 32/32.
Le graphique "polished" ci-dessous :
Note : Maximum et Running représentent respectivement la configuration maximale et minimale des instances du service ArcSOC. Dans ce cas Running a les mêmes valeurs et est tracé « derrière » Maximum. Busy représente le nombre d'instances actives (en raison des requêtes des utilisateurs) sur toutes les machines du Site.
L'objectif de l'ajustement et optimisation dans ce cas serait d'éviter que les valeurs Busy atteignent constamment Maximum. Si cela arrivait cela signifierait qu'il n'y avait pas assez d'ArcSOCs disponibles pour que le service réponde à la demande utilisateur car les instances étaient toujours occupées. Les requêtes utilisateur rencontreraient alors très probablement des temps de réponse et d'attente accrus dans le processus. Si les requêtes attendent trop longtemps dans le système elles expirent (typiquement après 60 secondes). Avoir beaucoup d'expirations de requêtes de service impacterait négativement l'expérience utilisateur.
D'après les observations durant cette période surveillée la montée et descente des valeurs de la colonne Busy ne s'est jamais approchée du nombre maximum d'instances disponibles... ce qui d'un certain point de vue était positif. Cependant cela indiquait aussi qu'il y avait un nombre mesurable d'instances en fonctionnement occupant de la mémoire mais non utilisées... ce qui n'était pas idéal.
Pour optimiser les ressources système à l'avenir la configuration des instances de ce service aurait pu être réglée sur une valeur plus basse plus proche du pic d'utilisation attendu (par exemple entre 18 et 24).
- Utiliser 18 pour économiser la mémoire avec le risque potentiel que plusieurs instances fassent attendre plus longtemps les utilisateurs pour leurs requêtes
- Utiliser 24 pour privilégier la performance plutôt que l'utilisation mémoire
Réflexions finales
Avoir une configuration « optimisée » du service pour le nombre minimum et maximum d'instances ne garantit pas que les utilisateurs ne rencontreront jamais de lenteurs. Les besoins et habitudes des utilisateurs changent avec le temps donc surveiller ces informations devra être fait périodiquement.
Dans la réalité il existe des conditions où des temps d'attente peuvent encore être rencontrés dans un déploiement... même avec suffisamment d'instances disponibles et beaucoup de ressources système. Il n'est pas réaliste d'éliminer complètement les temps d'attente mais il est plus pratique de les réduire. Optimiser les instances du service est quelque chose que les administrateurs peuvent contrôler directement et qui impacte les temps d'attente.
Comprendre et évaluer périodiquement la configuration des instances ArcSOC (pour les services dédiés) et sa relation avec la demande utilisateur est clé pour aider les administrateurs GIS à mieux planifier et gérer leur Site en optimisant la performance et en utilisant efficacement les ressources.
