Si des centaines ou des milliers d’utilisateurs accèdent à vos services, il peut être judicieux de modifier les valeurs par défaut des propriétés de service en fonction de 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 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
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 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 Service Editor (Éditeur 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 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 valide 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.
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, 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érieur à 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 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.
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 section Types de services de l’aide.
Vous avez un commentaire à formuler concernant cette rubrique ?