bureau SIG dans une boîte<\/A> par exemple. Comme dans tout bureau, l'équilibre entre le nombre de personnel, la demande et les ressources est un calcul permanent. Et cela est vrai aussi dans notre bureau ArcGIS dans une boîte. La plupart des bureaux SIG sont limités en capacité de personnel par des facteurs tels que les postes de travail disponibles, la bande passante réseau ou les licences des logiciels essentiels. Si nous manquons de bureaux et d'ordinateurs que les analystes peuvent utiliser, nous ne pouvons pas ajouter plus d'analystes au bureau. Si tous les analystes travaillent sur certaines tâches, nous ne pouvons pas demander à ce qu'une nouvelle tâche soit commencée. Même si nous agrandissons l'espace et ajoutons de l'infrastructure, nous ne pouvons pas utiliser cette capacité accrue si nous n'achetons pas plus de licences d'ArcGIS Pro. Avec ArcGIS Server, nous pouvons faire face aux mêmes défis et limites. Il est donc vital de configurer les services web SIG (services) fonctionnant dans ArcGIS Server pour utiliser efficacement les ressources finies disponibles, tout en assurant le meilleur débit et la meilleure vitesse pour le système.<\/P> <\/P>
Chaque service non hébergé dans ArcGIS Server dispose d'un ensemble d'options de configuration qui peuvent être définies au moment de la publication dans ArcGIS Pro ou après publication avec l'application web administrative ArcGIS Server Manager. Un service peut exister dans ArcGIS Server dans plusieurs états. D'abord il est publié. Cela signifie qu'un fichier de définition de service a été créé, et qu'il existe dans le répertoire Server dans un sous-dossier appelé arcgisinput, par défaut situé à C:\arcgisserver\directories\arcgissystem\arcgisinput. Ensuite, le service peut être en cours d'exécution ou arrêté. Par défaut, les services publiés sont démarrés lors de la publication, bien que les services puissent aussi être arrêtés. Lorsqu'un service est démarré et en cours d'exécution, il est « annoncé » dans une autre application web appelée ArcGIS Server Services Directory. Ici, les administrateurs, éditeurs et développeurs trouvent des propriétés utiles et des opérations supportées qui peuvent être utilisées pour inspecter et utiliser les services.<\/P>
<\/P>
Un autre résultat du démarrage d'un service dans ArcGIS Server est que les composants gestionnaires de notre « bureau » démarreront le nombre minimum d'instances défini pour le service, par défaut c'est une instance. Techniquement, une instance d'un service est une unité de traitement unique, généralement manifestée comme un processus ArcSOC.exe s'exécutant dans le système d'exploitation de l'ordinateur hôte. Vous pouvez penser à une instance d'un service comme un analyste assis à un bureau avec le projet ArcGIS Pro requis disponible qui peut répondre aux demandes pour des capacités définies de la ressource SIG annoncée. Notez que le nombre d'instances en cours d'exécution n'est pas directement lié au nombre d'applications ni aux personnes « utilisant » le service. Dans ce cas, l'instance fonctionne et attend simplement une requête. C'est ce qu'on appelle l'état inactif de l'instance.<\/P>
<\/P>
ArcGIS Server Manager et Gestionnaire des tâches Windows montrant des instances d'un service web SIG.<\/span><\/span><\/P> <\/P>Le nombre minimum d'instances définit combien d'instances du service sont démarrées lorsque le service est lancé. Cela peut être réglé à n'importe quel nombre y compris zéro. Mais ne soyez pas excessif avec ce nombre, rappelez-vous que le serveur SIG dispose de ressources finies disponibles et qu'il y a très probablement d'autres services en cours d'exécution qui ont besoin d'utiliser ces ressources pour supporter leurs propres instances également. Mais ce n'est que le minimum. Il y a aussi un nombre maximum d'instances qui peuvent être instanciées. Ce maximum peut être supérieur ou égal au minimum d'instances. Par défaut, ce nombre est deux. Donc, par défaut lorsqu'un service est publié sur ArcGIS Server, le plus grand nombre d'analystes virtuels pouvant exister pour répondre aux requêtes vers ce service est deux. Est-ce suffisant ? Très probablement non. Surtout si c'est un service à demande moyenne à élevée. Mais encore une fois, rappelez-vous que bien que vous puissiez définir ce maximum à n'importe quel nombre, vous pouvez facilement surcharger votre système en permettant la création de plus d'instances que ce que le système total peut gérer. De plus, il y aura d'autres services fonctionnant dans ArcGIS Server avec leurs propres instances qui doivent consommer ces ressources finies également.<\/P> <\/P>
ArcGIS Server Manager avec paramètres de configuration des instances.<\/span><\/span><\/P> <\/P>Jusqu'à ArcGIS 10.7, c'était la seule façon de contrôler le nombre d'analystes (instances) existant dans notre bureau SIG (ArcGIS Server). Toutes les instances existantes dans ArcGIS Server étaient définies séparément pour chaque service et ne pouvaient répondre qu'aux requêtes pour ce service uniquement. On peut considérer cela comme si chaque analyste dans notre bureau SIG ne pouvait ouvrir qu'un seul projet à la fois dans ArcGIS Pro et que le projet ne pouvait contenir qu'une seule carte, scène, modèle ou autre ressource SIG unique avec laquelle l'analyste pouvait interagir pour répondre aux requêtes. Ce sont ce qu'on appelle des instances dédiées.<\/P> <\/P>Puis à ArcGIS 10.7, nous avons introduit un nouveau concept : la piscine partagée d'instances (shared instance pool). Les instances dans cette piscine peuvent répondre aux requêtes vers n'importe quel service qui lui est assigné, avec certaines limites sur les types de services pouvant y être affectés. Vous pouvez considérer cette piscine partagée comme un certain nombre d'analystes dans notre bureau ayant une copie du même projet ouverte dans ArcGIS Pro qui contient plusieurs cartes (une pour chaque service assigné à la piscine) disponibles dedans. L'avantage apporté est que les services à faible demande ont déjà des instances en fonctionnement pour les supporter rapidement, mais les ressources informatiques ne sont pas gaspillées sur des instances inutilisées.<\/P> <\/P>Une dernière considération lorsque l'on parle des instances d'un service est que tous les services auxquels nos utilisateurs ont accès ne sont pas gérés comme des services séparés dans ArcGIS Server. Par exemple, lorsque vous publiez un service cartographique (map service), un service cartographique est mis à disposition dans Server Manager pour gérer des propriétés telles que le nombre min/max d'instances. Ce service cartographique possède également sa propre URL ou point final par lequel les clients communiquent. Mais l'objet du service cartographique dans ArcGIS Server Manager possède aussi une propriété capabilities (capacités). Par cette propriété, des capacités supplémentaires peuvent être activées comme la capacité feature access (accès aux entités). L'activation de celle-ci fera qu'ArcGIS Server créera une autre URL pour un feature service (service entité). Mais ce feature service et tout autre service activé via une capacité ne crée pas ses propres instances. Les instances originales créées pour le service cartographique associé supportent aussi le feature service.<\/P> <\/P>
ArcGIS Server Manager montrant l’URL d’un service cartographique.<\/span><\/span><\/P> <\/P>
ArcGIS Server Manager montrant l’URL d’un feature service.<\/span><\/span><\/P> <\/P>À travers cet article nous avons vu qu'il existe plusieurs façons de contrôler et gérer les services web SIG afin d'influencer la performance fournie par ArcGIS Server. Mais ArcGIS Server n'est qu'une partie du processus de création, gestion et partage des ressources SIG. Dans la plupart des cas, les décisions que nous prenons concernant le stockage des données SIG ou la création des ressources auront un impact plus important que ces options. Dans le programme de formation dirigée par un instructeur Esri, nous discutons et mettons en œuvre plusieurs techniques spécifiques d’optimisation du contenu dans notre cours
