Skip to main content

Optimiser les services en fonction des besoins des utilisateurs

Les valeurs par défaut des propriétés de service peuvent ne pas être adaptées aux besoins de vos utilisateurs. C’est particulièrement vrai s’il y a un grand nombre d’utilisateurs ou si ces derniers adressent de nombreuses demandes à votre site ArcGIS Server. Cette rubrique vous donne une vue d’ensemble des concepts, propriétés et techniques permettant de mieux configurer vos services.

Comprendre les instances de service

Lorsqu’une demande est adressée à un service de votre site ArcGIS Server (par exemple, pour se déplacer dans une carte, accéder à une adresse ou afficher une image avec une règle de rendu), elle est gérée par une instance du service publié exécuté sur une machine serveur. Les instances de service sont alimentées par les processus serveur propriétaires d’Esri, appelés processus ArcSOC. Chaque processus ArcSOC, pour être exécuté, utilise une certaine quantité de mémoire de votre machine.

S’il existe un grand nombre de services sur votre site ArcGIS Server et que chacun utilise une ou plusieurs instances de service qui s’exécutent en permanence, la quantité de mémoire disponible sur votre ordinateur risque d’atteindre sa limite. L’exécution de ces instances de service représente également un coût énergétique pour votre organisation, et si vous déployez ArcGIS Server sur une infrastructure cloud, vous devrez supporter un coût financier direct pour chaque instance de service que vous exécutez.

En conséquence, il est important que les administrateurs d’ArcGIS Server surveillent le nombre d’instances exécutées par leur site et limitent le nombre d’instances en cours d’exécution lorsque les performances sont entravées par la quantité de mémoire utilisée.

Les utilisateurs espèrent des résultats rapides lorsqu’ils interagissent avec vos services (ou avec les produits qui reposent sur ces services, tels que les applications et cartes web). Des processus ArcSOC adéquats sont requis pour gérer le trafic reçu par vos services. Toutefois, fournir une quantité de ressources serveur supérieure à celle requise par un service est source de gaspillage en termes de quantité de mémoire des ordinateurs, d’énergie et d’argent. Les administrateurs doivent donc s’efforcer de réduire le nombre d’instances de service en cours d’exécution au minimum sans pour autant affecter les performances.

Instances de service partagées et dédiées

ArcGIS Server permet d’utiliser des instances partagées ou des instances dédiées pour chaque service de carte ou d’imagerie compatible publié sur un site ArcGIS Server à partir d’ArcGIS Pro. L’utilisation d’instances partagées permet de préserver la quantité de mémoire utilisée en regroupant plusieurs processus serveur actifs à utiliser par plusieurs services. D’autre part, les instances dédiées mettent toujours un service à disposition pour le traitement des requêtes grâce à un ou plusieurs traitements serveur et conviennent parfaitement aux services qui reçoivent des requêtes fréquentes ou exigeant beaucoup de ressources de calcul.

Pour les nouveaux déploiements d’ArcGIS Server, les instances partagées sont la norme par défaut. Les administrateurs peuvent à la fois choisir un type d’instance par défaut (que les services de carte compatibles doivent ou non utiliser initialement des instances partagées ou dédiées) et changer le type d’instance d’un service spécifique à tout moment.

Conseil :

Pour déterminer l’application à partir de laquelle un service a été publié, consultez les propriétés Service Runtime (Environnement d’exécution du service) et Instance Type (Type d’instance) de chaque service dans l’application ArcGIS Server Manager.

Les restrictions suivantes limitent les services qui peuvent utiliser le groupe d’instances partagées :

  • Seuls les services de carte et d’imagerie peuvent être configurés de sorte à utiliser le groupe d’instances partagées. Les autres types de service, tels que les services de géotraitement, ne sont pas pris en charge.

  • Seules les fonctionnalités suivantes peuvent être activées : cartographie, imagerie, accès aux entités, WFS, WMS et KML. Désactivez toutes les autres fonctionnalités avant de convertir un service dédié en service partagé.

Un service d’imagerie ou de carte à instance dédiée s’exécute à l’aide d’un groupe désigné de processus ArcSOC. Les processus de ce groupe ne seront utilisés pour aucun autre service. Un service d’imagerie ou de carte à instance partagée s’exécute à l’aide d’un groupe de processus ArcSOC qui sont également utilisés pour tout autre service d’instance partagée. Par défaut, chaque processus ArcSOC d’instance partagée met en cache les 50 derniers services utilisés afin qu’ils soient prêts à traiter des demandes. Si un processus ArcSOC d’instance partagée contient déjà le nombre maximal de services mis en cache lorsqu’un utilisateur adresse une demande sur un nouveau service, le processus ArcSOC déchargera le premier service utilisé et chargera le nouveau service. Si les utilisateurs adressent régulièrement des demandes sur plus de 50 services d’instance partagée, vous pouvez augmenter le nombre par défaut de services mis en cache par instance partagée.

Quand utiliser chaque type d’instance

Les instances partagées sont généralement préférables aux instances dédiées. Les instances partagées offrent une plus grande efficacité globale car elles ont la même performance médiane et le même débit, mais nécessitent beaucoup moins de ressources système.

Des instances dédiées sont recommandées dans deux situations.

  • Pour des raisons commerciales, un petit ensemble de services exige une performance et une évolutivité accrues par rapport à d’autres services.

  • Lorsque des fonctionnalités ne sont pas prises en charge sur des instances partagées telles que les SOE qui ne sont pas sécurisées pour les threads ou les réseaux de distribution.

Le fait de désigner des services comme dédiés n’améliorera pas automatiquement les performances. Pour optimiser les performances avec des instances dédiées, vous devez également réduire le nombre d’instances disponibles pour les instances partagées et définir soigneusement le nombre d’instances pour votre service dédié. Le fait de désigner trop de services comme dédiés risque de nuire aux performances. Il est recommandé d’avoir le moins possible de services de carte ou d’imagerie dédiés par site.

Les services de cartes et d’imagerie sont très gourmands en processeurs. En général, le débit d’une instance ArcGIS Server axée sur des services de cartes et d’imagerie est limité par le nombre de cœurs de processeur. Si votre machine serveur possède huit cœurs et que tous vos services sont des instances partagées, le débit maximal est probablement atteint lorsque la machine travaille sur huit demandes simultanées. ArcGIS Server traite davantage de demandes, mais ces demandes supplémentaires partageront les processeurs. Tous les services utilisant des instances partagées sont traités avec la même priorité et peuvent utiliser toute la puissance de processeur de votre serveur.

Les instances dédiées conviennent à un service nécessitant des performances constantes, même si cela provoque une baisse des performances des autres services. Par exemple, si vous disposez de huit cœurs, vous pouvez en réserver la moitié uniquement pour ce service en définissant le nombre minimal et maximal d’instances dédiées sur quatre. Pour garantir qu’au moins quatre cœurs restent disponibles pour ce service dédié en permanence, vous pouvez réduire le nombre d’instances partagées à quatre afin qu’elles n’utilisent jamais plus que l’autre moitié des huit cœurs.

ArcGIS Server permet la sur-allocation des instances. Cela signifie que même si une machine ne possède que huit cœurs, vous pouvez attribuer plus d’instances que vous n’avez de cœurs. Bien que la sur-allocation soit possible, elle rend difficiles la prévision et le contrôle des performances. L’utilisation d’une sur-allocation de 10 % à 20 % peut améliorer l’efficacité, mais un facteur important de sur-allocation risque de nuire à vos performances. Au lieu de sur-allouer des instances dédiées, vous constaterez probablement une amélioration des performances en convertissant certains services dédiés en instances partagées.

Nombres minimal et maximal d’instances de service

Lorsqu’un service utilise des instances dédiées, vous pouvez ajuster le nombre maximal et minimal d’instances autorisé par machine. Ces paramètres peuvent aider les services de votre site à prendre en compte les variations dans le volume de trafic.

La propriété de nombre minimal d’instances représente le nombre d’instances dédiées déjà créées et disponibles pour être utilisées pour un service sur chaque machine ArcGIS Server. Par exemple, si vous définissez ce paramètre sur trois instances, au moins trois instances sont exécutées sur les processus ArcSOC à tout moment, même si le service ne reçoit aucune demande. Si vous n’êtes pas certain que de nombreux utilisateurs utiliseront simultanément un service, envisagez de diminuer le nombre minimal d’instances.

La propriété de nombre maximal d’instances représente le plus grand nombre d’instances de ce service exécuté sur une machine ArcGIS Server donnée. En tant qu’administrateur, déterminez le nombre d’instances d’une configuration de service qui satisfait la demande prévue des utilisateurs à un niveau de performances acceptable.

Le nombre d’instances dont vous avez besoin dans une configuration de service se détermine le mieux en surveillant votre serveur dans le temps. Si les temps d’attente de votre client sont longs ou que les demandent expirent, vous devrez peut-être ajuster le nombre d’instances disponibles ou la manière dont votre application utilise ces instances.

Prenez en compte la durée pendant laquelle les utilisateurs utiliseront vos services. Certaines demandes adressées au serveur exigent plus de travail que d’autres. Le traitement d’un grand nombre de demandes légères pour des services risque d’être moins problématique pour le serveur qu’un nombre plus réduit de demandes exigeant un travail intensif. Chaque service possède une propriété définissant un temps d’attente maximal et une propriété définissant un temps d’utilisation maximal. Si les demandes des utilisateurs pour un service expirent à plusieurs reprises, envisagez d’augmenter le temps d’attente maximal ou le nombre d’instances disponibles du service.

Une fois que vous avez déterminé le nombre d’instances prenant en charge vos clients, divisez-le par le nombre de machines ArcGIS Server de votre déploiement et utilisez le nombre ainsi obtenu afin de définir le nombre maximal d’instances pour la configuration du service. Par exemple, si vous avez besoin d’un maximum de dix instances d’un service pour en gérer simultanément les demandes et que vous disposez de deux machines ArcGIS Server, spécifiez le nombre maximal d’instances sur cinq.

Chaque instance consomme de la mémoire, même si le service n’est pas utilisé. Le fait de définir un nombre minimal d’instances par machine inférieur au nombre maximal d’instances par machine vous permet de libérer de la mémoire lorsqu’elle n’est pas utilisée. Cette fonctionnalité a généralement un impact limité sur les performances. Lorsque de nouvelles instances doivent être démarrées, les demandes peuvent subir un délai. Pour éviter ce délai, vous pouvez définir un nombre minimal d’instances par machine égal au nombre maximal d’instances par machine.

Utilisez les fichiers journaux et les statistiques du serveur pour déterminer si des demandes excessives provoquent le dépassement des délais d’expiration et si des services sont utilisés au-delà de leur temps d’utilisation maximal. Utilisez Server Manager pour ajuster le nombre d’instances de services disponibles, ainsi que le temps d’attente et d’utilisation maximal d’un service.

Groupage d’instances de service

Tous les services publiés avec ArcGIS Server sont groupés. Cela signifie que les instances du service peuvent être partagées entre plusieurs sessions d’application.

Une application qui utilise une instance de service groupé l’utilise seulement pendant la durée nécessaire à l’exécution d’une requête (affichage d’une carte ou géocodage d’une adresse, par exemple). Une fois la requête terminée, l’application diffuse sa référence au service et la renvoie directement au groupe disponible d’instances.

Recyclage des instances de service

Le recyclage de services permet de détruire des services inutilisables et de les remplacer par de nouveaux services ; cela permet également de récupérer des ressources utilisées par des services périmés.

Les services sont habituellement partagés par plusieurs applications et par leurs utilisateurs. Grâce à la fonction de réutilisation, un certain nombre d’événements peut rendre un service indisponible pour les applications. Par exemple, une application peut modifier, de manière incorrecte, l’état d’un service ou encore conserver la référence à un service plus longtemps que prévu, le rendant ainsi indisponible pour d’autres applications ou sessions. Dans certains cas, les services peuvent être endommagés ou inutilisables. Le recyclage permet de conserver le groupe de services actualisés et de se débarrasser des services inutilisables ou périmés.

Pendant le processus de recyclage, le serveur détruit, puis recrée chaque instance de la configuration des services. Le recyclage s’effectue en arrière-plan sur le serveur. Bien que rien à l’écran ne vous indique que le recyclage est en cours, les événements associés à cette opération apparaissent dans les fichiers journaux.

Le recyclage détruit et recrée toutes les instances en cours d’exécution d’un service, que ces instances soient au-delà du minimum spécifié ou non. Pour renvoyer périodiquement le nombre d’instances en cours d’exécution au minimum spécifié, le service doit être arrêté puis redémarré. Pour automatiser ce processus, vous pouvez créer un script de lot Python, shell ou Windows qui exécute un fichier exécutable personnalisé de ligne de commande d’API administrative ArcGIS Server. Ce fichier exécutable personnalisé adopte en tant qu’arguments de ligne de commande le nom du serveur, le nom du service, le type du service et si le service doit être démarré ou arrêté.

Le temps écoulé entre les événements de recyclage est l’intervalle de recyclage. L’intervalle de recyclage par défaut est de 24 heures, valeur que vous pouvez modifier dans la boîte de dialogue Service Editor (Éditeur de services). Vous pouvez également sélectionner l’heure du recyclage initial de la configuration. À partir de ce moment, le recyclage aura lieu chaque fois que l’intervalle de recyclage sera atteint.

Les services sont recyclés instance par instance pour s’assurer que les instances restent disponibles et pour répartir les pertes de performance consécutives à la création d’une instance de chaque service. Le recyclage s’effectue de manière aléatoire ; cependant, les instances de services en cours d’utilisation ne sont pas recyclées tant qu’elles n’ont pas été libérées. De cette manière, les activités de recyclage sont réalisées sans interrompre l’utilisateur d’un service.

Si le nombre d’instances disponibles au cours du recyclage est insuffisant, une requête est mise en file d’attente jusqu’à ce qu’une instance soit disponible. Si la durée d’attente maximale du service est atteinte, les journaux enregistrent le message qu’ils sont censés enregistrer.

Recherche de connexions de données non valides

Si une instance du service est inactive, un administrateur de serveur peut avoir du mal à déterminer si les connexions aux données source restent valides. ArcGIS Server est doté de mécanismes intégrés permettant de rechercher les connexions non valides aux géodatabases d’entreprise. Grâce à ces vérifications, votre service ne semble pas ne pas répondre après suppression ou interruption d’une connexion à la base de données.

Remarque :

La prise en charge de la vérification des connexions de données non valides n’inclut pas les géodatabases fichier.

Vous pouvez activer les vérifications de validité des connexions de données depuis l’onglet Processes (Processus) de la boîte de dialogue Service Editor (Éditeur de services) dans ArcGIS Server Manager en cochant la case Periodically check and repair data connections for idle instances (Contrôler et réparer régulièrement les connexions de données des instances inactives). Vous devez également préciser l’intervalle, en minutes, auquel les connexions de service seront automatiquement validées (et réparées si nécessaire). La valeur par défaut de 30 minutes est habituellement appropriée.

Ces vérifications peuvent également s’avérer utiles si des pare-feu ferment les ports aux géodatabases d’entreprise lorsque vos services restent inactifs pendant un certain laps de temps. Dans ce cas, prenez en compte les paramètres d’expiration des pare-feu pour définir l’intervalle de vérification.

Nombre de demandes ayant atteint la limite d’attente

En comprenant les diverses valeurs d’expiration des services, vous pourrez assurer le fonctionnement et la disponibilité de vos services. Ces valeurs sont disponibles dans l’onglet Pooling (Groupage) de la boîte de dialogue Service Editor (Éditeur de services).

Dès qu’un client reçoit une référence à un service, il utilise ce dernier pendant une certaine période avant de le libérer. L’intervalle entre le moment où le client reçoit une référence à un service et le moment où il le libère est appelé temps d’utilisation. Pour s’assurer que les clients ne conservent pas trop longtemps des références à des services (c’est-à-dire s’ils ne libèrent pas correctement les services), une valeur Maximum time a client can use a service (Durée maximale pendant laquelle un client peut utiliser un service) est attribuée à chaque service. Si un client conserve un service plus longtemps que le temps d’utilisation maximum, le service est automatiquement libéré et le client perd sa référence au service.

Pour aller plus loin :

Lorsque vous créez un service, la valeur par défaut de durée d’utilisation maximale est de 600 secondes (10 minutes). Toutefois, dans le service PublishingTools, généré au préalable, qui est intégré à chaque site ArcGIS Server, le temps d’utilisation maximal est défini sur 3 600 secondes (60 minutes). Elle est adaptée aux tâches de publication pour lesquelles des volumes importants de données sont copiés sur le serveur.

L’application d’un temps d’utilisation maximum empêche également que des services soient utilisés dans le cadre de volumes de travail plus importants que ceux prévus par l’administrateur. Par exemple, un service utilisé par une application pour exécuter des extractions dans une géodatabase peut présenter un temps d’utilisation maximum de 10 minutes. En revanche, un service à une couche utilisé uniquement à dessiner des cartes dans une application, peut présenter un temps d’utilisation maximum d’une minute.

Lorsque le nombre maximum d’instances d’un service est utilisé, tous les clients demandant un service sont placés dans une file d’attente jusqu’à ce qu’un autre client libère un des services. L’intervalle entre le moment où un client formule une requête de service et le moment où il reçoit celui-ci est appelé temps d’attente. Une valeur Maximum time a client will wait to get a service (Durée maximale pendant laquelle un client peut utiliser un service) est attribuée à chaque service. Si la durée d’attente d’un client est supérieure à la durée d’attente maximale d’un service, la requête expire.

Un troisième délai d’expiration détermine la valeur Maximum time an idle instance can be kept running (Durée maximale de fonctionnement d’une instance inactive). Lorsque les services deviennent inutilisables, ils restent en cours d’exécution sur le serveur jusqu’à ce qu’un autre client ait besoin de l’instance. Une instance en cours d’exécution inutilisée consomme toujours de la mémoire sur le serveur. Vous pouvez réduire le nombre de services en cours d’exécution et économiser ainsi de la mémoire en réduisant ce délai d’inactivité (la valeur par défaut est de 1 800 secondes, soit 30 minutes). Un délai d’inactivité court présente un inconvénient : lorsque tous les services en cours d’exécution expirent, les clients suivants doivent attendre la création de nouvelles instances.

Lorsque des instances du service sont créées dans le serveur SIG, soit à la suite du démarrage du serveur ou en réponse à une demande adressée au serveur par un client, le temps nécessaire pour initialiser l’instance du service correspond à son temps de création. Le serveur SIG respecte un délai d’expiration du démarrage qui définit le temps dont dispose un service pour démarrer avant que le serveur SIG ne suppose que son démarrage a été suspendu et qu’il n’annule la création de l’instance du service. La valeur par défaut est de 300 secondes (5 minutes).

Le serveur conserve, à la fois en mémoire et dans ses journaux, des statistiques relatives au temps d’attente, à la durée d’utilisation et à d’autres événements qui se produisent sur le serveur. L’administrateur du serveur peut utiliser ces statistiques pour déterminer si, par exemple, le temps d’attente d’un service est long, ce qui peut indiquer que le nombre maximum d’instances doit être augmenté pour ce service.

Des expirations supplémentaires peuvent avoir lieu dans votre architecture, ce qui provoquera des différences entre les valeurs d’expiration du service que vous spécifiez et les expirations réelles rencontrées par les clients. Par exemple, le serveur Web hébergeant ArcGIS Web Adaptor ou un système d’équilibrage de la charge réseau peut imposer des expirations qui affectent vos services.

Remarque :

Si votre site est très sollicité, attendez-vous à des différences entre les valeurs d’expiration que vous spécifiez et les expirations rencontrées par les clients.

Limitation des opérations que les utilisateurs peuvent effectuer avec un service

Pour faciliter le contrôle de l’utilisation de vos services web, chaque type de service permet l’exécution de certaines opérations. Chaque opération est constituée d’un jeu de méthodes qui peuvent être activées ou désactivées ensemble. Les clients du service Web ne peuvent appeler que les méthodes relatives aux opérations autorisées.

Supposez que vous voulez autoriser les utilisateurs d’un service web de cartographie à dessiner une carte sans pouvoir interroger les sources de données des couches de la carte. Vous devez, dans ce cas, désactiver l’opération de données et vérifier que l’opération de carte est bien autorisée.

Les services d’entités présentent un intérêt particulier dans cette discussion, car ils permettent de mettre à jour des données SIG sur le web. Ils proposent des opérations supplémentaires permettant de limiter les fonctions de mise à jour. Vous pouvez activer ou désactiver ces opérations dans l’onglet Feature Access (Accès aux entités) de la boîte de dialogue Service Editor (Éditeur de services) dans ArcGIS Server Manager. Vous pouvez également empêcher des utilisateurs de mettre à jour des entités qu’ils n’ont pas créées en activant le contrôle d’accès basé sur la propriété.

Pour en savoir plus sur les opérations autorisées dans les différents types de services, reportez-vous à la rubrique Types de services.

Scénarios pour l’optimisation des services

Les scénarios suivants fournissent quelques exemples concrets de la manière dont un administrateur peut optimiser les services pour répondre aux besoins des utilisateurs.

Scénario : temps de réponse lent du service

Un utilisateur dans votre organisation vous signale des durées d’attente inacceptables pour afficher un service de carte spécifique. Après avoir testé le service de carte, vous découvrez qu’une couche spécifique du service de carte met du temps à s’afficher. Pour mieux comprendre le problème, vous résoudre le problème de performance du service de carte à l’aide des journaux du serveur et vous isolez les informations concernant ce service de carte.

Cause potentielle n°1

Après avoir examiné les journaux du gestionnaire de serveur, vous découvrez qu’une couche (ou plusieurs) du service mettent trop longtemps à s’afficher.

Solution courante au problème n°1

Utilisez les meilleures pratiques suivantes pour optimiser les performances de la carte :

  • Utilisez le rendu dépendant de l’échelle.

  • Supprimez les blocs de données et les couches inutilisés.

  • Utilisez la validation des ensembles de définition.

  • Simplifier la symbologie des couches

  • Utilisez des cartes mises en cache lorsque c’est possible (si les données sont rarement modifiées, par exemple).

Après avoir vérifié le service, appliqué les conseils d’optimisation et republié le service, vous et vos collègues constatez une amélioration considérable de la réactivité du service de carte.

Cause potentielle n°2

Les journaux Server Manager indiquent qu’un ralentissement de l’accès réseau à une couche du service peut ralentir les performances de ce dernier.

Solution courante au problème n°2

Utilisez les meilleures pratiques suivantes pour accéder aux données et les gérer en vue de limiter la latence du réseau et d’optimiser les performances des services :

Après avoir vérifié le service, appliqué les conseils relatifs à l’accès et à la gestion des données, et republié le service, vous et vos collègues constatez une amélioration considérable de la réactivité du service de carte.

Scénario : garantir la présence de ressources adéquates sur la machine

Vous avez créé une application Web très attendue et souhaitez la proposer à un plus large public à une date fixée plus tard dans la semaine. Puisque vous prévoyez une demande accrue des services proposés par cette application, vous voulez vous assurer que vous disposez des ressources machine suffisantes pour en faciliter l’utilisation.

Afin d’allouer suffisamment de ressources, en termes de serveurs, pour prendre en charge l’utilisation intensive de cette application Web, vous allez examiner les statistiques d’ArcGIS Server et identifier les services rarement utilisés, puis ajuster leurs propriétés en conséquence, afin de permettre aux utilisateurs d’accéder plus facilement à cette application. Vous allez ensuite ajuster comme il convient les propriétés des services qui seront utilisés dans l’application Web.

Solution potentielle

Gérez et ajustez les propriétés des services pour allouer des ressources à votre site. Prenez par exemple en compte la durée d’utilisation des services par les utilisateurs. Sont-ils utilisés au-delà de la durée d’utilisation maximum ? Les utilisateurs remarquent-ils des dépassements de délais d’expiration dus au volume excessif des requêtes soumises à un service ?

Utilisez les recommandations suivantes pour ajuster les propriétés des services etanticiper les besoins des utilisateurs pour mieux y répondre :

  • Identifiez les services les plus utilisés et augmentez le nombre minimum d’instances pour chacun. Vous réduirez ainsi le temps d’attente des utilisateurs.

  • Migrez les services en utilisant des instances dédiées qui peuvent utiliser le groupe d’instances partagées à la place.

  • Augmentez le nombre minimum et maximum d’instances, ainsi que le temps d’attente, d’inactivité et d’utilisation, comme il convient, pour limiter les ralentissements côté utilisateurs.

  • Réduisez le nombre d’instances, ainsi que le temps d’attente et d’inactivité, comme il convient, afin de libérer des ressources système pour les services en ayant le plus besoin.