Les clients souhaitent et attendent un service rapide. En conséquence, vos services de géotraitement doivent être rapides et efficaces. Comme ArcGIS Server peut prendre en charge plusieurs clients à la fois, des services inefficaces risquent de surcharger votre serveur. À ressources informatiques équivalentes, plus vos services sont efficaces, plus nombreux sont les clients pouvant être pris en charge.
Vous trouverez ci-dessous des conseils et des techniques pour augmenter les performances de vos services. En général, les techniques sont présentées dans l'ordre. Celles qui offrent les améliorations de performances les plus conséquentes sont présentées en premier. Les derniers conseils peuvent vous faire gagner quelques dixièmes de seconde sur votre temps d'exécution, ce qui peut être utile pour certaines tâches.
Utilisation de couches pour les données de projet
Lorsque vous exécutez un outil de géotraitement pour créer un résultat à publier, vous devez utiliser 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 relatives au 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. Quand le service s'exécute, 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é, ce qui constitue un réel gain de performance.
Par exemple, le service Champ de vision hébergé sur Esri SampleServer et l'Extension ArcGIS Network Analyst, qui créent des polygones de temps de conduite, utilisent tous deux des couches. En fonction de la taille du jeu de données, vous pouvez gagner plus de 1 à 2 secondes par exécution de service.
Utilisation de données stockées en local sur ArcGIS for Server
Les données de projet nécessaires aux services de géotraitement doivent être stockées en local sur ArcGIS for 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 il n'est pas rare de constater que la lecture et l'écriture de données sur un réseau LAN prend deux fois plus de temps que sur un disque local.
Ecriture de données intermédiaires en mémoire
Vous pouvez écrire des données intermédiaires (temporaires) en mémoire. L'écriture de données en mémoire est plus rapide que leur écriture sur disque.
Remarque :
Vous pouvez également écrire des données en sortie en mémoire, tant que vous n'utilisez pas de service de carte obtenu.
Prétraitez les données utilisées par vos tâches
La plupart des services de géotraitement sont censés être des applications spécialisées offrant des réponses aux requêtes spatiales spécifiques posées par les clients Web. Les tâches 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 simple d'optimisation des opérations de sélection spatiale et attributaire. Autres exemples :
- Dans le didacticiel Exemple de service de géotraitement : bassin versant, un raster d'accumulation et de direction de flux est créé pour prétraiter des données hydrologiques.
- Vous pouvez précalculer des distances à partir d'emplacements connus à l'aide des outils Proche ou Générer la table de proximité. Par exemple, supposons que votre service permet aux clients de sélectionner des parcelles vacantes situées à une distance définie 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 bien plus rapide de précalculer la distance entre chaque parcelle et le fleuve Los Angeles River (avec l'outil Proche) et de stocker les distances calculées en tant qu'attributs des parcelles. Vous indexerez alors ces attributs à 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 simple et rapide parmi les attributs de distance, plutôt qu'une requête spatiale moins efficace.
Ajout d'un index attributaire
Si votre tâche sélectionne des données à l'aide de requêtes attributaires, créez un index attributaire pour chaque attribut utilisé dans les requêtes. Vous pouvez utiliser l'outil Ajouter un index attributaire. Vous devez créer l'index une seule fois et le faire en dehors de votre modèle ou de votre script.
Ajout d'index spatiaux
Si votre modèle ou votre script formule des requêtes spatiales sur les fichiers de formes, créez un index spatial pour le fichier de formes à l'aide de l'outil Ajouter un index spatial. Si vous utilisez des classes d'entités de géodatabase, les index spatiaux sont créés automatiquement et mis à jour pour vous. Dans certaines circonstances, recalculer un index spatial permet d'améliorer les performances, comme décrit dans la rubrique Définition des index spatiaux.
Utilisation de tâches synchrones plutôt qu'asynchrones
Vous pouvez indiquer au service de géotraitement de s'exécuter en mode synchrone ou asynchrone. En mode asynchrone, le temps système d'exécution du serveur est légèrement plus long. En conséquence, les tâches asynchrones s'exécutent rarement en moins d'une seconde. L'exécution de la même tâche en mode synchrone est plus rapide d'un dixième de seconde que son exécution en mode asynchrone.
Evitez des transformations de coordonnées inutiles
Si la tâche utilise des jeux de données exprimés dans des systèmes de coordonnées différents, les outils de géotraitement de la tâche 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 des coordonnées d'un système de coordonnées en un autre peut ralentir la tâche. Vous devez donc connaître les systèmes de coordonnées de vos jeux de données et identifier le besoins éventuels en termes de conversion de ces systèmes par les outils de la tâche. Vous pouvez choisir de convertir tous les jeux de données utilisés par la tâche en un seul et même système de coordonnées. Pour plus d'informations sur les systèmes de coordonnées et sur leur impact sur les outils de géotraitement, reportez-vous aux rubriques suivantes :
Réduisez la taille de données
Tous les logiciels de traitement de données fonctionnent plus rapidement quand le jeu de données est petit. Il existent quelques manières de réduire la taille de vos données géographiques :
- Supprimez les attributs inutiles de vos données de projet avec l'outil Supprimer un champ.
- Les entités linéaires et surfaciques possèdent des sommets qui définissent leur forme. Chaque sommet est une coordonnée x,y. Vos entités possèdent peut-être plus de sommets que nécessaire, ce qui augmente inutilement la taille de votre jeu de données.
- Si vos données proviennent d'une source externe, elles 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, vos entités contiennent des détails qui sont adaptés à une grande échelle, mais votre analyse ou votre présentation est à une petite échelle.
Différences entre la version 10.0 et les versions ultérieures
Si vous avez créé des services de géotraitement dans la version 10.0, vous avez utilisé les techniques d'optimisation de la performance indiquées ci-dessous. Vous n'avez plus besoin d'utiliser ces techniques dans la version 10.1 et les versions ultérieures.
Héritage :
Avant la version 10.1, si votre configuration ArcGis for Server comportait plusieurs machines ou si vous utilisiez des chemins UNC vers le répertoire arcgisjobs, il était recommandé de paramétrer un répertoire de tâches local. Ce répertoire de tâches local améliorait sensiblement le temps d'exécution car le traitement de chaque tâche se faisait sur le serveur local, puis le résultat final était transmis au client. À partir de la version 10.1, la configuration de répertoires de tâches locaux est une tâche d'administrateur du serveur SIG. Ainsi, en tant que créateur de tâches, vous n'avez plus besoin de spécifier que votre tâche utilise le répertoire de tâches local puisqu'il est automatiquement utilisé si le serveur fait partie d'un cluster de plus d'une machine ou que les répertoires sont référencés à l'aide d'un chemin UNC.
Héritage :
Avant la version 10.1, si le service de géotraitement s'exécutait sur des rasters, il était préférable de les mettre au format GRID. Certains outils étant optimisés pour ce format, l'exécution était généralement plus rapide. À partir de la version 10.1, tous les outils raster peuvent désormais lire et écrire le format source sans aucune perte de performance.
Rubriques connexes
Vous avez un commentaire à formuler concernant cette rubrique ?