Optimiser le calcul de ses caches (Episode 3/3)
Nous terminons aujourd'hui notre série d'article consacrés à l'optimisation du calcul de caches avec ArcGIS Server. Aujourd'hui, nous nous focaliserons sur le paramétrage des tuiles du cache.
Paramétrage des tuiles
La première question qu'il faut trancher c'est le choix d'un cache fusionné (fused) ou d'un cache multi-couche (multi-layer). Le cache fusionné permet de n'avoir qu'une seule imagette à charger pour chaque tuile de la carte. Beaucoup plus rapide à générer, le cache fusionné est également beaucoup moins volumineux en termes d'espace disque. En revanche, à la différence du cache multi-couche, le cache fusionné ne permet pas de rendre visible telle ou telle couche dans l'application cliente.
Un bon compromis peut consister à regrouper de manière logique certaines couches de la carte et de créer ainsi 3 caches fusionnés plutôt qu'un cache multi-couche de 12 couches.
Si vous optez pour un cache multi-couche, vous prendrez garde aux options d'anti-aliasing qui peuvent aboutir par le jeu des superpositions des couches à des rendus dégradés.
La deuxième question est généralement celle de la taille des tuiles du cache (hauteur et largeur en pixels). Il conviendra de considérer le temps de création mais aussi leur utilisation dans les applications clientes, en particulier le nombre de tuiles par affichage.
Plus la taille des tuiles est petite, plus elles se chargent vite dans l'application cliente donnant ainsi une impression de performance. Cependant, les navigateurs ont un nombre maximum de requêtes http pouvant être émises simultanément vers un même serveur (par exemple 4 en http 1.1 pour IE). Ceci peut donc constituer une limite sur la parallélisassions de la récupération des tuiles.
Plus la taille des tuiles est grande moins il y aura de tuiles à créer, ce qui réduit le temps de création. On retiendra en moyenne un gain de temps d'environ 10 à 15% entre la génération de tuiles de 256x256 par rapport à des tuiles de 512x512.
Lorsque le cache n'a pas besoin d'être actualisé, il est possible de déconnecter le service de carte des données d'origine en créant un MXD factice (ne contenant pas de couches) et en le publiant en lieu et place du MXD original avec un nombre minimal d'instance. Si les applications clientes nécessitent d'interroger les entités de la carte, il est possible de créer un service dédié à cette tâche, en créant par exemple un MXD ne contenant que les couches nécessaires et en le publiant avec simplement la capacité Query.
Le choix de la taille des tuiles (en pixels) a une incidence directe sur la taille moyenne (en octets). Dans le cas de caches volumineux, il conviendra de réfléchir à la taille de block unitaire du disque dur qui hébergera vos caches. En effet, si vous choisissez une taille de tuile de 128x128 vous pouvez avoir par exemple une tuile de 1024 octets. Si la taille des blocs unitaires de votre disque dur est de 4Ko 4096), votre imagette occupera quasiment 4 fois plus de volume que nécessaire. Sur l'ensemble d'un cache vous pouvez retrouver des écarts importants, ci-dessous un exemple pris sur un de mes caches. Le volume de stockage de mon cache est 40% supérieur à la taille réelle des tuiles.
Le choix du format et de la compression des imagettes est également un critère important. Vous réserverez le format JPEG pour les cartes contenant de l'imagerie (orthophoto, satellitaire, MNT, …). Dès que la carte contient des zones de couleurs homogènes, on utilisera plutôt le format PNG. C'est le nombre de nuances et les capacités de transparence qui vous guiderons ensuite entre le 8bits, 24bits ou 32bits.
Conclusion
Le calcul de cache est un processus qui nécessite la mise en place d'une réflexion préalable pour optimiser à la fois la phase de calcul mais également la phase de maintenance ou encore son exploitation dans les applications clientes. Au-delà des préconisations de cette série d'articles, le plus important est probablement l'expérimentation. Réalisez des tests sur des zones restreintes (mais représentatives) de votre carte pour extrapoler ensuite à l'ensemble du jeu de données. Si vous avez des projets d'envergure mettant en jeu des caches, nous avons à ESRI France une grande expérience sur le sujet (ArcGIS Online, plateforme des services web Cartosphère, expérience clients, …) et nous pourrons vous conseiller.
1 comments :
ne pas oublier non plus l'indexation/rtree des raster éventuellement employés... Au sein d'un catalog managé ou non, les mécanismes d'index réduisent considérablement le temps de création du cache (et également le temps d'impression, dans le cas de l'emploi de mapbook par exemple).
Enregistrer un commentaire