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.

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 géodatabase d'entreprise, de groupe de travail et de bureau. Grâce à ces vérifications, votre service ne semble pas ne pas répondre après suppression ou interruption d'une connexion à géodatabase d'entreprise, de groupe de travail et de bureau.

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 habituellement appropriée.

Ces vérifications peuvent également s'avérer utiles si des pare-feu ferment les ports à géodatabase d'entreprise, de groupe de travail et de bureau 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.

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 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.

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.

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. 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é.

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