Les utilisateurs comptent sur des outils aussi rapides que possible. En conséquence, votre outil Web ou service de géotraitement doit être efficace. ArcGIS Server pouvant prendre en charge plusieurs clients à la fois, des services inefficaces risquent de surcharger les ressources de votre serveur. À ressources informatiques équivalentes, plus les services sont efficaces, plus nombreux sont les clients pouvant être pris en charge.
Utilisation de couches pour les données de projet
Lorsque vous exécutez un outil avant de le partager en tant qu’outil Web, utilisez des couches comme données en entrée plutôt que des chemins vers des jeux de données situés sur le disque. Une couche référence un jeu de données sur le disque et certaines couches mettent en cache des propriétés du jeu de données. Cela est particulièrement vrai pour les couches de jeu de données réseau et les couches raster. L’utilisation d’une couche à la place du chemin vers le jeu de données présente un avantage en termes de performances car lorsque le service est lancé, il crée la couche à partir du jeu de données, met en cache les propriétés de base du jeu de données et garde le jeu de données ouvert. Lors de l’exécution du service, les propriétés du jeu de données sont immédiatement disponibles, le jeu de données est ouvert et prêt à être manipulé.
Par exemple, ArcGIS Network Analyst extension crée des polygones isochrones qui utilisent des couches. En fonction de la taille du jeu de données, vous pouvez gagner de 1 à 2 secondes par exécution de service.
Conseil :
Consultez un exemple d’utilisation des couches dans les outils de script Python.
Utilisation de données locales sur ArcGIS Server
Les données de projet nécessaires à l’outil Web doivent être locales sur ArcGIS Server. Les données qui sont partagées et auxquelles vous accédez via un partage réseau (UNC) sont plus lentes que si elles étaient situées sur une même machine. Les chiffres des performances varient beaucoup, mais la lecture et l’écriture de données sur un réseau LAN prennent généralement deux fois plus de temps que sur un disque local.
Écriture de données intermédiaires en mémoire
Écrivez des données intermédiaires dans l’espace de travail memory. L’écriture de données en mémoire est plus rapide que leur écriture sur disque.
Remarque :
Les données en sortie peuvent être écrites en mémoire à partir du moment où l’option d’affichage des sorties en tant que couche d’images de carte n’est pas définie.
Prétraitement des données utilisées par les tâches
La plupart des outils Web sont censés être des workflows spécialisés offrant des réponses aux requêtes spatiales spécifiques posées par les clients web. Ces workflows ayant tendance à être des opérations spécifiques sur des données connues, vous pouvez presque toujours prétraiter les données en vue d’optimiser l’opération. Par exemple, l’ajout d’un attribut ou d’un index spatial est un prétraitement d’optimisation des opérations de sélection spatiale et attributaire.
Les distances à partir d’emplacements connus peuvent être calculées à l’aide de l’outil Near (Proche) ou Generate Near Table (Générer la table de proximité). Par exemple, supposons qu’un service permette aux clients de sélectionner des parcelles vacantes situées à une distance spécifiée par l’utilisateur du fleuve Los Angeles. Vous pouvez utiliser l’outil Sélectionner une couche par emplacement pour effectuer cette sélection, mais il est beaucoup plus rapide de précalculer la distance de chaque parcelle par rapport à Los Angeles River (à l’aide de l’outil Proche) et de stocker la distance calculée en tant qu’attribut des parcelles. Vous indexerez alors cet attribut à l’aide de l’outil Ajouter un index attributaire. Lorsque le client émet une requête, la tâche peut ainsi effectuer une sélection d’attributs parmi les attributs de distance, plutôt qu’une requête spatiale, moins efficace.
Ajout d’un index attributaire
Si l’outil sélectionne des données à l’aide de requêtes attributaires, créez un index attributaire pour chaque attribut utilisé dans les requêtes grâce à l’outil Ajouter un index attributaire. Il suffit de créer l’index une seule fois, notamment en dehors du modèle ou du script.
Ajout d’index spatiaux
Si le modèle ou le script formule des requêtes spatiales sur des shapefiles, créez un index spatial pour le shapefile à l’aide de l’outil Ajouter un index spatial. Pour les classes d’entités de géodatabase, les index spatiaux sont créés et gérés automatiquement. Dans certains cas, le recalcul d’un index spatial permet d’améliorer les performances, comme indiqué dans la rubrique Index spatiaux dans la géodatabase.
Utilisation du mode synchrone plutôt qu’asynchrone pour les outils à exécution rapide
Un outil Web peut être configuré de sorte à être exécuté de manière synchrone ou asynchrone. En cas d’exécution asynchrone, le temps système d’exécution du serveur est plus long. L’exécution d’une même tâche est toujours plus rapide de manière synchrone qu’asynchrone. Toutefois, pour les tâches à exécution longue, la différence devient marginale et les services synchrones ne peuvent pas fournir les statistiques et messages pendant l’exécution de l’outil, ce qui peut nuire à la qualité de l’expérience.
Pas de transformations de coordonnées inutiles
Si l’outil Web utilise des jeux de données exprimés dans des systèmes de coordonnées différents, les outils devront peut-être les convertir en un seul et même système de coordonnées au cours de l’exécution. En fonction de la taille des jeux de données, la conversion d’un système de coordonnées en un autre peut inutilement ralentir les performances. Vous devez donc connaître les systèmes de coordonnées des jeux de données et identifier les éventuelles obligations de conversion de ces systèmes par les outils.
Réduction de la taille des données
Tous les logiciels de traitement de données fonctionnent plus rapidement quand le jeu de données est petit. Voici quelques méthodes permettant de réduire la taille des données géographiques :
- Supprimez les attributs inutiles des données de projet à l’aide de l’outil Delete Field (Supprimer un champ).
- Les entités linéaires et surfaciques possèdent des sommets qui définissent leur forme. Les entités possèdent peut-être plus de sommets que nécessaire, ce qui augmente inutilement la taille du jeu de données.
- Les données peuvent contenir des sommets en double ou des sommets si proches les uns des autres qu’ils ne contribuent pas à la définition de l’entité.
- Le nombre de sommets n’est pas ajusté à l’échelle d’analyse. Par exemple, les entités contiennent des détails qui sont adaptés à une grande échelle, mais l’analyse ou la présentation est à une petite échelle.
Vous avez un commentaire à formuler concernant cette rubrique ?