Optimisation et configuration des services

ArcGIS for Desktop vous aide à publier des services immédiatement en définissant automatiquement de nombreuses propriétés par défaut des services. Cependant, si des centaines ou des milliers d'utilisateurs accèdent à vos services, vous souhaiterez peut-être modifier les valeurs par défaut des propriétés des services 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

Tous les services publiés avec ArcGIS 10.1 for Server et les versions ultérieures 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

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 ArcGIS Server administrative. 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 Editeur de services. 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 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.

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.

Services à niveau d'isolement élevé s'exécutant 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 à un processus de gérer plusieurs 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 24 instances au maximum de la même configuration de service peuvent partager un processus. Vous pouvez définir la valeur de l'option Instances par processus dans l'onglet Processus de la boîte de dialogue Editeur de services. Une fois ce nombre d'instances créé pour un service particulier, le serveur démarre un processus supplémentaire pour le groupe d'instances suivant, et ainsi de suite. Les instances remplissent et libèrent les espaces de ces processus en cours d'exécution lorsqu'ils sont créés et détruits.

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 permet d'utiliser légèrement moins 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. Il est fortement recommandé d'utiliser un isolement élevé.

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 Editeur de services dans ArcGIS for Desktop ou 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 généralement 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 temps. Dans ce cas, prenez en compte les paramètres d'expiration des pare-feu pour définir l'intervalle de vérification.

Délais d'expiration

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 Groupage de la boîte de dialogue Editeur 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 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), une 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.

Approfondissement :

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, la durée d'utilisation maximale est définie 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 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 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 durée maximale pendant laquelle un client attend un service est attribuée à chaque service. Si la durée d'attente d'un client est supérieur à la durée d'attente maximale d'un service, la requête expire.

Un troisième délai d'expiration détermine la 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 requête 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.

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 d'un 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 : Interroger, Créer, Mettre à jour et Supprimer. Vous pouvez désactiver ou activer ces opérations dans l'onglet Accès aux fonctions de la boîte de dialogue Editeur de services d'ArcGIS for Desktop. 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é.

Les tables suivantes présentent des méthodes activées lorsque vous autorisez des opérations sur divers types de services :

Opérations des services cartographiques

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

Carte	Requête	Données
GetDocumentInfo	Identifier	Rechercher
GetLegendInfo	QueryFeatureCount	QueryData
GetMapCount	QueryFeatureCount2	QueryFeatureData
GetMapName	QueryFeatureIDs	QueryFeatureData2
GetDefaultMapName	QueryFeatureIDs2	QueryAttachmentInfos
GetServerInfo	QueryHyperlinks	QueryAttachmentInfos2
GetSupportedImageReturnType	QueryHTMLPopups	QueryAttachmentData
ExportMapImage	QueryHTMLPopups2	QueryAttachmentData2
IsFixedScaleMap	GetSQLSyntaxInfo	QueryRelatedRecords
ToMapPoints		QueryRelatedRecords2
FromMapPoints		QueryRasterValue
HasSingleFusedMapCache		QueryRasterValue2
GetTileCacheInfo
GetMapTile
HasLayerCache
GetLayerTile
GetVirtualCacheDirectory
GetCacheName
ComputeScale
ComputeDistance
ExportScaleBar
GetCacheDescriptionInfo
GetCacheControlInfo
GetCacheStorageInfo
GetDefaultLayerDrawingDescriptions
GetMapTableSubtypeInfos
GetMapTableSubtypeInfos2
GetServiceConfigurationInfo

Opérations des services de géocodage

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

Géocodage	Géocodage inverse
GeocodeAddress	ReverseGeocode
GeocodeAddresses
StandardizeAddress
FindAddressCandidates
GetAddressFields
GetCandidateFields
GetIntersectionCandidateFields
GetStandardizedFields
GetStandardizedIntersectionFields
GetResultFields
GetDefaultInputFieldMapping
GetLocatorProperties

Opérations des services de géodonnées

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

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

Opérations des services de globe

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.

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

Opérations des services d'imagerie

Si vous avez publié le service d'imagerie à partir d'une 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.

Image	Catalogue	Téléchargez	Métadonnées	Pixels
ExportImage	Champs	Téléchargez	Métadonnées	GetNativePixelBlock
ExportMapImage	GetCatalogItemCount	GetFile	GetRasterMetadata	GetPixelBlock
GenerateServiceInfo	GetCatalogItemIDs
GetImage	GetCatalogItems
Identifier	GetNativeRasterInfo
ServiceInfo	GetRasterInfo
Version	GetThumbnail