Réglage et configuration des services

S'agissant de la publication des services, ArcGIS Server définit automatiquement de nombreuses propriétés par défaut, ce qui rend l'opération à la fois simple et rapide. Cependant, si des centaines ou des milliers d'utilisateurs accèdent à votre service ou si certains d'entre eux y effectuent des opérations dynamiques (une mise à jour, par exemple), il s'avérera judicieux de modifier les valeurs par défaut afin de les adapter à votre déploiement. Cette rubrique vous donne un aperçu de certaines propriétés et techniques permettant de mieux configurer vos services.

Groupage

Vous pouvez modifier les propriétés d'un service afin que ce dernier soit groupé ou non groupé. Les instances d'un service groupé peuvent être partagées entre plusieurs sessions d'application. Lorsqu'une session d'application renvoie au serveur une instance de service groupé, cette instance peut être utilisée par d'autres sessions d'application. En conséquence, les services groupés doivent être utilisés uniquement avec des opérations passives.

A l'opposé, les instances d'un service non groupé sont consacrées à une seule session d'application. L'instance d'un service non groupé est détruite lorsqu'une session d'application la renvoie au serveur. Les services non groupés sont utilisés lorsque l'application doit effectuer des opérations dynamiques, telles que la modification avec fonction annuler/répéter activée.

Avec les configurations groupées et non groupées, vous devez spécifier un nombre minimal et un nombre maximal d'instances lors de l'ajout du service. Lorsque vous commencez à configurer le service, le serveur SIG crée et initialise le nombre minimum d'instances. Lorsqu'une application demande au gestionnaire des objets serveur (SOM) une instance de ce service, elle reçoit une référence à l'une des instances. Si toutes les instances sont en cours d'utilisation, le serveur en crée une nouvelle. Il procédera de la sorte pour chaque demande ultérieure, jusqu'à ce que la capacité de toutes les machines conteneurs ou le nombre maximal d'instances autorisé pour la configuration ait été atteint (selon le premier critère rencontré).

Services groupés

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. Il se peut que les personnes qui utilisent ce type d'application travaillent avec plusieurs instances différentes d'un service du groupe lorsqu'ils interagissent avec l'application. Cela est transparent pour les utilisateurs, dans la mesure où toutes les instances du groupe ont le même état.

Par exemple, une application passive qui souhaite tracer une étendue spécifique d'une carte recevra une référence à une instance d'un service cartographique du groupe, exécutera une méthode sur le service en question afin de dessiner la carte, puis la retransmettra au groupe. La prochaine fois que l'application devra dessiner une carte, elle suivra cette même procédure. Chaque affichage de la carte peut utiliser une instance différente du service groupé ; toutes les instances doivent donc être identiques (disposer du même jeu de couches, de la même représentation pour chaque couche, etc.). Si un utilisateur modifie l'état d'une instance en ajoutant une couche ou en modifiant la représentation d'une couche, par exemple, il obtiendra des résultats incohérents lorsqu'il effectuera des opérations de déplacement et de zoom sur la carte. Cela est dû au fait que l'instance dont l'état a été modifié a été renvoyée au groupe et que rien ne garantit à l'utilisateur que le groupe lui livrera cette instance spécifique chaque fois qu'il demandera un service. Il échoit au développeur de s'assurer que l'application ne modifie pas l'état de l'instance et que cette dernière est renvoyée au groupe dans les délais impartis.

Le groupage des services permet au serveur SIG de prendre en charge davantage d'utilisateurs en allouant moins de ressources à un service spécifique. Etant donné que les applications peuvent partager un groupe d'instances, le nombre d'utilisateurs simultanés sur le système peut être supérieur à ce qu'il serait possible d'obtenir si chaque utilisateur conservait une référence à une instance dédiée.

Les services groupés peuvent prendre en charge davantage d'utilisateurs car les sessions d'application partagent un ensemble de services au sein du groupe.

Services non groupés

En règle générale, une application qui utilise une instance de service non groupé conserve sa référence à l'instance pendant toute la durée de la session. Lorsque l'application libère l'instance, elle est détruite et le serveur SIG en crée une nouvelle afin de maintenir le nombre d'instances disponibles. C'est la raison pour laquelle l'utilisateur d'un service non groupé peut apporter des modifications aux données sous-jacentes du service.

Avec les services non groupés, la corrélation entre le nombre d'utilisateurs sur le système et le nombre d'instances en cours d'exécution ne peut pas dépasser 1:1. Le nombre d'utilisateurs simultanés que le serveur SIG peut prendre en charge est donc égal au nombre de services non groupés qu'il peut prendre en charge à un moment donné.

Pour que votre serveur SIG prenne en charge le plus grand nombre possible d'utilisateurs simultanés, évitez d'utiliser des services non groupés, à moins que vous n'en ayez besoin pour les opérations dynamiques, telles que la mise à jour Web de données versionnées. Lorsque vous développez des applications avec des services non groupés, veillez à détruire les instances du service dès que vous n'en avez plus besoin. Si vous créez dans le Gestionnaire une application de mise à jour Web qui utilise des services non groupés, incitez les utilisateurs à cliquer sur le lien Fermer lorsqu'ils quittent l'application. De cette façon, les instances de service non groupé sont immédiatement détruites, sans avoir à attendre qu'elles expirent.

AttentionAttention :

N'utilisez pas les services non groupés avec des connexions Serveur Internet ArcGIS. Utilisez plutôt des connexions Serveur local ArcGIS.

Recyclage

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 groupés sont en général partagés par plusieurs applications et par les utilisateurs de ces applications. 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. Notez que le recyclage ne s'applique pas aux services non groupés dans la mesure où ces derniers sont créés explicitement pour être utilisés par un client particulier et sont détruits après leur utilisation.

Pendant le processus de recyclage, le serveur détruit, puis recrée chaque instance d'une configuration de services groupés. 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é. Afin d'automatiser ce processus, vous pouvez créer un script de lot Python, shell ou Windows qui exécute un fichier exécutable de ligne de commande d'API ArcGIS Server personnalisé. 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é. Il est implémenté à l'aide des commandes IServerObjectAdmin.StartConfiguration et IServerObjectAdmin.StopConfiguration.

Afficher un code d'exemple pour arrêter et démarrer des services.

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 Propriétés du service. Vous pouvez également sélectionner l'heure du recyclage initial de la configuration. A 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 de services disponibles en cours de recyclage s'avère insuffisant, une demande est mise en file d'attente jusqu'à ce qu'une instance soit disponible. Si la durée d'attente maximale (MaximumWaitTime) est atteinte durant ce laps de temps, les fichiers journaux enregistrent le message qu'ils sont censés enregistrer.

Si vous modifiez les données sous-jacentes d'un service, cette modification est automatiquement répercutée après le recyclage. Par exemple, si un service de carte est en cours d'exécution et que vous modifiez le document ArcMap qui lui est associé, vous aurez la possibilité de visualiser la modification une fois le recyclage terminé. (Pour visualiser directement les modifications, vous pouvez démarrer et arrêter le service.)

Isolement

Lorsque vous créez un service, vous devez définir le nombre minimum et maximum d'instances que vous souhaitez rendre disponibles. Ces instances s'exécutent sur les machines conteneurs dans le cadre de leurs processus. Le niveau d'isolement détermine si ces instances doivent être exécutées dans le cadre de processus distincts ou communs.

Si l'isolement est élevé, chaque instance s'exécute dans son propre processus. Si le processus échoue pour une raison ou une autre, seule l'instance active en est affectée.

Les services à niveau d'isolement élevé s'exécutent dans des processus dédiés sur le serveur SIG.

A l'opposé, un isolement faible autorise plusieurs instances d'une configuration de service à partager un seul processus. Cela permet l'exécution de quatre requêtes indépendantes simultanées. C'est ce que l'on appelle le "multi-threading".

Si l'isolement est faible, 8 instances par défaut et 256 instances au maximum de la même configuration de service peuvent partager un processus. Vous pouvez définir le nombre d'Instances par processus dans l'onglet Processus de la boîte de dialogue Propriétés du service. Une fois ce nombre d'instances d'un service particulier créé, le serveur démarre un processus supplémentaire pour le prochain groupe d'instances, et ainsi de suite. Les instances remplissent et libèrent les espaces de ces processus en cours d'exécution au fur et à mesure de leur création et de leur destruction.

Un faible isolement présente l'avantage d'augmenter le nombre d'instances simultanées prises en charge par un seul processus. L'utilisation d'un isolement faible peut considérablement améliorer la consommation de mémoire sur votre serveur. Cette amélioration présente toutefois certains risques. Ainsi, si un processus s'arrête ou se bloque, toutes les instances qui le partagent sont détruites. Un isolement faible réduit également l'efficacité du rétrécissement de groupe, puisque toutes les instances d'un processus doivent devenir inutilisables avant que le rétrécissement de groupe ne puisse supprimer ledit processus.

Notez que les services non groupés sont toujours exécutés dans le cadre de leur propre processus. Le niveau d'isolement ne s'applique donc pas.

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 ArcSDE. Grâce à ces vérifications, votre service ne semble pas ne pas répondre après suppression ou interruption d'une connexion à ArcSDE.

Vous pouvez activer les vérifications de validité des connexions de données en ouvrant l'onglet Processus de la boîte de dialogue Propriétés du service dans ArcCatalog ou dans le Gestionnaire, puis en cochant la case 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 à ArcSDE lorsque vos services restent inactifs pendant un certain laps de temps. Dans ce cas, prenez en compte les paramètres des délais d'expiration des pare-feu pour définir l'intervalle de vérification.

ApprofondissementApprofondissement :

Par défaut, ArcGIS Server exécute déjà des vérifications sur les services occupés afin de valider et de réparer les connexions de données. Toutes les 5 minutes, la prochaine requête reçue par un service engendre une vérification. Vous pouvez modifier l'intervalle ou désactiver ce comportement en ajoutant la balise ConnectionCheckInterval à la section <Propriétés> du fichier de configuration de service. Pour plus d'informations sur la balise ConnectionCheckInterval, reportez-vous à la rubrique Fichiers de configuration du service.

La balise ConnectionCheckInterval ne peut pas valider les connexions de données sur les services inactifs.

Délais d'expiration

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 la 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), un temps d'utilisation maximum pendant lequel un client peut utiliser un service est attribué à 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.

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 utilisé par des applications servant uniquement à dessiner des cartes, peut présenter un temps d'utilisation maximum d'une minute.

Lorsque le nombre maximum d'instances d'un service groupé ou non groupé est en cours d'utilisation, tous les clients formulant une requête de service sont placés dans une file d'attente jusqu'à ce qu'un autre client libère l'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. Un temps d'attente maximum avant qu'un client ne puisse accéder à un service est attribué à chaque service. Si le temps d'attente d'un client est supérieur au temps d'attente maximum d'un service, la requête expire.

Un troisième délai d'expiration concerne la durée maximale pendant laquelle une instance peut s'exécuter. 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 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 services sont créés dans le serveur SIG, soit à la suite du démarrage du serveur ou en réponse à une requête adressée au serveur par un client, le temps nécessaire pour initialiser le 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 du service. Cette propriété peut uniquement être configurée en modifiant manuellement le fichier de configuration du service.

Le serveur conserve, à la fois en mémoire et dans ses fichiers journaux, des statistiques relatives au temps d'attente, au temps d'utilisation et à d'autres événements qui se produisent au sein du 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.

Limitation de la charge sur le serveur à l'aide de la propriété Capacité

La capacité limite le nombre d'instances du service qui peuvent s'exécuter sur une machine conteneur d'objets serveur (SOC). Par défaut, elle est illimitée. Toutefois, si vous disposez d'une machine dont la mémoire est limitée, vous pouvez définir une limite de capacité afin de vous assurer que les instances en cours d'exécution n'aient pas un impact trop considérable sur la mémoire.

Dès que le nombre d'instances de service en cours d'exécution sur une machine conteneur atteint la capacité maximale, le serveur cesse d'en créer de nouvelles sur cette machine. Si toutes les machines conteneurs ont atteint leur capacité maximale, l'opération de rétrécissement de groupe entre en action.

Lorsque vous définissez des valeurs de capacité, veillez à ne pas confondre les instances en cours d'exécution et celles "en cours d'utilisation". Les instances en cours d'exécution consomment de la mémoire, mais n'utilisent pas le processeur. Les instances en cours d'utilisation consomment de la mémoire et utilisent le processeur. Ainsi, un serveur prenant en charge uniquement quatre instances en cours d'utilisation à la fois peut être capable de prendre en charge davantage d'instances en cours d'exécution si la mémoire RAM est suffisante. Les instances en cours d'exécution restent disponibles immédiatement et à tout moment.

Si votre machine est dotée de suffisamment de mémoire, conservez une capacité Illimitée.

ApprofondissementApprofondissement :

Le serveur exécute toujours un processus ArcSOC.exe supplémentaire en arrière-plan, qui gère l'utilisation des répertoires de serveur. Ce processus n'a aucune incidence sur la capacité.

Adaptation du serveur à la demande : rétrécissement de groupe

Que se passe-t-il lorsqu'un serveur SIG atteint la capacité maximale sur toutes ses machines conteneurs ? ArcGIS Server applique le concept de rétrécissement de groupe. Cette opération supprime les instances de service des configurations les moins utilisées et les remplace par des instances des configurations plus usitées.

Le rétrécissement de groupe s'active lorsque le nombre d'instances de service en cours d'exécution a atteint la capacité maximale sur chaque machine conteneur. Lorsque cela s'est produit et que le gestionnaire des objets serveur a reçu une demande de service, le serveur crée l'instance demandée et détruit une instance de la configuration de service la moins récemment utilisée. Vous trouverez, ci-après, une description détaillée des capacités et limites du rétrécissement de groupe :

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 possède un ensemble d'opérations autorisées. 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 qui ont été autorisées.

Supposez que vous voulez autoriser les clients d'un service Web de cartographie à dessiner une carte sans qu'ils puissent interroger les sources de données des couches de la carte. Vous devez, dans ce cas, désactiver l'opération de requête et vérifier que l'opération de carte est bien autorisée.

Si vous créez un service à l'aide de l'assistant Ajouter un nouveau service (plutôt que l'assistant Publier une ressource SIG), vous pouvez sélectionner les opérations autorisées lorsque vous créez le service. Quelle que soit la manière dont vous avez initialement créé un service, vous pouvez modifier les opérations qui sont autorisées sur ce service en modifiant les propriétés du service. Les opérations disponibles sont répertoriées dans l'onglet Fonctionnalités de la boîte de dialogue Propriétés du service.

Les tableaux ci-dessous répertorient les méthodes incluses dans chaque opération:

Opérations des services cartographiques

Carte

Requête

Données

GetDocumentInfo

Identifier

Rechercher

GetLegendInfo

QueryFeatureCount

QueryFeatureData

GetMapCount

QueryFeatureIDs

GetMapName

QueryHyperlinks

GetDefaultMapName

GetSQLSyntaxInfo

GetServerInfo

GetSupportedImageReturnType

ExportMapImage

IsFixedScaleMap

ToMapPoints

FromMapPoints

HasSingleFusedMapCache

GetTileCacheInfo

GetMapTile

HasLayerCache

GetLayerTile

GetVirtualCacheDirectory

GetCacheName

ComputeScale

ComputeDistance

Les opérations autorisées par défaut pour les services cartographiques sont Carte, Requête et Données.

Opérations des services de géocodage

Géocodage

Géocodage inverse

GeocodeAddress

ReverseGeocode

GeocodeAddresses

StandardizeAddress

FindAddressCandidates

GetAddressFields

GetCandidateFields

GetIntersectionCandidateFields

GetStandardizedFields

GetStandardizedIntersectionFields

GetResultFields

GetDefaultInputFieldMapping

GetLocatorProperties

Les opérations autorisées par défaut pour les services de géocodage sont Géocodage et Inverser le géocodage.

Opérations des services de géodonnées

Requête

Extraction

Réplication

Get_Versions

ExpandReplicaDatasets

CreateReplica

Get_DefaultWorkingVersion

ExtractData

ExportAcknowledgement

Get_DataElements

ExportReplicaDataChanges

Get_MaxRecordCount

ImportAcknowledgement

TableSearch

ImportReplicaDataChanges

GetNextResultPortion

ReExportReplicaDataChanges

Get_Replicas

UnregisterReplica

Get_WrappedWorkspaceType

ImportData

Les opérations autorisées par défaut pour les services de géodonnées sont Requête et Extraction, ce qui permet d'utiliser toutes les méthodes d'interrogation et d'extraction de données prises en charge. L'option Réplication permet d'utiliser toutes les méthodes prises en charge pour la synchronisation, les mouvements de données, l'accusé de réception des messages et les structures.

Opérations des services de globe

Globe

Animation

Requête

Get_Version

Get_Animation

Identifier

Get_LayerCount

Rechercher

Get_LayerInfos

Get_LegendInfos

Get_Config

Get_MQT

Get_Configuration

Get_Tile

Get_Symbols

Get_Textures

Get_VirtualCacheDirectory

Les opérations autorisées par défaut pour les services de globe sont Globe, Animation et Requête. A la différence des services cartographiques, l'opération de requête couvre l'identification et la recherche.

Opérations des services d'imagerie

Image

Catalogue

Télécharger

Métadonnées

Pixels

ExportImage

Fields

Download

Metadata

GetNativePixelBlock

ExportMapImage

GetCatalogItemCount

GetFile

GetRasterMetadata

GetPixelBlock

GenerateServiceInfo

GetCatalogItemIDs

GetImage

GetCatalogItems

Identifier

GetNativeRasterInfo

ServiceInfo

GetRasterInfo

Version

GetThumbnail

Si vous avez publié le service d'imagerie à partir d'un jeu de données en mosaïque, toutes les fonctionnalités sont activées par défaut. Si vous avez publié le service à partir d'une autre source (jeu de données raster, définition de service d'imagerie compilée ou fichier de couches, par exemple), seules les fonctions Image et Métadonnées s'appliquent et sont activées.


Copyright © 1995-2012 Esri. Tous droits réservés.
7/10/2012