Optimiser le calcul de ses caches (Episode 2/3)
Nous poursuivons notre série de recommandations pour optimiser le temps de calcul des caches ArcGIS Server. Nous abordons aujourd'hui l'aspect configuration matérielle et logicielle.
Préparation matérielle et logicielle
De manière générale, le calcul de cache est une opération très consommatrice en ressources en particulier sur les entrées-sorties sur les disques. Le premier conseil est donc d'utiliser des disques rapides (au moins 7200 tour par minutes). Ceci est vrai pour le stockage des tuiles mais également pour les disques hébergeant les données sources.
Si possible, utiliser la dernière version 9.3.1. Tout d'abord parce que cette version vous permet l'utilisation des services optimisés qui vous permettrons potentiellement des gains de performance et de qualité d'image très significatifs. Au-delà, même sur les services de carte classiques, les opérations d'écriture des tuiles sur le disque ont été optimisées dans cette version 9.3.1.
Si le calcul de cache est une opération fréquente dans votre organisation, ne pas hésiter à dédier une machine (4 cœurs est un bon point de départ). Si cela n'est pas possible, on retiendra la règle de lancer les calculs de cache dans les phases d'activité restreinte du serveur en hésitant pas à diminuer le nombre d'instance des services non concernés par le calcul de cache.
Si vous pouvez disposer de plusieurs machines pour héberger les processus ArcSOC, une bonne pratique est de travailler niveau d'échelle par niveau d'échelle. Dans le cas de très gros volumes (plusieurs millions de tuiles), ne pas hésiter à mettre en place une stratégie de découpage par zones géographiques en utilisant les options offertes par l'outil de géotraitement "Manage Map Server Cache Tiles". Dans tous les cas, ne pas hésiter dans un premier temps, à stocker les différentes parties du cache sur différents disques durs. Pour rassembler les caches sur un même disque des logiciels de copie spécialisés permettent la copie (rapide) de plusieurs millions de fichiers. A défaut, une bonne stratégie consiste à passer par des fichiers ZIP en compressant/décompressant chaque répertoire ou sous-répertoire du cache. Cela vous assurera au final un gain de temps et la certitude de copier correctement tous vos fichiers.
Un paramètre important lors du calcul du cache est le nombre d'instance du service à utiliser. Même si il peut y avoir quelques divergences sur les retours d'expérience, le nombre optimum est au minimum le nombre de CPU et au maximum le nombre de cœur. Par exemple pour un serveur 2CPU/2Core, on peut mettre en place 4 instances pour le calcul de cache. Dans le doute, 2 instances est généralement la valeur optimum. Il conviendra de réserver 2 Go de RAM pour chaque instance.
Une bonne pratique, sous Windows, consiste à désactiver l'option d'indexation du dossier contenant les caches (option "Avancé" puis décocher l'option "Indexer ce dossier pour une recherche rapide" dans les propriétés du dossier sous Windows XP/Vista). Certains utilisateurs font remonter un gain entre 15% et 20% que personellement je n'ai pas réussi à démontrer sur ma propre machine.
Si d'autres services cohabitent sur votre serveur pendant le calcul des caches, suivre l'évolution de la consommation de la RAM avec le gestionnaire de tâches. Il faut en effet éviter que la quantité de mémoire physique manque et que les services utilisent le fichier de pagination ce qui aurait des conséquences très néfastes sur les temps de calcul.
Si vous jugez que la quantité de RAM peut être insuffisante pendant la production du cache, une bonne pratique peut consister à déplacer le fichier de pagination pagefile.sys sur un disque différent de celui stockant les caches.
A demain pour la fin de cet article …
