Mise en cache à la demande

ArcGIS vous permet de créer des tuiles de cache de carte à la demande au fur et à mesure que les utilisateurs y accèdent. Le premier utilisateur qui accède à une surface non mise en cache doit attendre que les tuiles correspondantes soient affichées par le serveur. Les tuiles sont ensuite ajoutées au dossier de cache du service et demeurent sur le serveur jusqu’à ce qu’elles soient mises à jour ou supprimées par l’administrateur du serveur. Cela signifie que les visiteurs suivants sur la surface n’auront pas à attendre que la tuile soit créée.

Lorsqu’elle est utilisée judicieusement, la mise en cache à la demande peut vous faire gagner beaucoup de temps et libérer de l’espace disque. La plupart des cartes affichent des surfaces stériles, inutilisables ou sans intérêt pour le public de la carte, en particulier à grande échelle (zoom avant). La mise en cache à la demande vous évite de créer et de stocker ces tuiles inutiles, mais laisse la possibilité à un utilisateur d’afficher la surface s’il le souhaite.

Bien que la mise en cache à la demande soit une fonction utile, elle peut affecter les performances si elle est utilisée à mauvais escient ou trop souvent. Les sections suivantes offrent des astuces pour utiliser la mise en cache à la demande de la façon la plus efficace possible.

Optimisation des performances

Un des avantages de la mise en cache de carte complète est qu’elle vous permet d’afficher des cartes complexes rapidement, car le site ArcGIS Server distribue des images tuilées de la carte ; il n’affiche pas la carte à chaque demande. Toutefois, lorsque vous utilisez la mise en cache à la demande, le site ArcGIS Server doit afficher les tuiles dynamiquement lorsqu’un utilisateur accède à une zone non mise en cache. Cet affichage dynamique prend plus de temps qu’une demande standard, car le site ArcGIS Server crée un groupe de tuiles à la fois. La taille du groupe de tuiles est de 2 048 x 2 048 pixels si le service de carte utilise l’anti-crénelage, et de 4 096 x 4 096 pixels dans le cas contraire. Par conséquent, vous devez préparer votre carte pour l’affichage de grandes surfaces à une vitesse acceptable.

Approfondissement :

Dans ce cas, le site ArcGIS Server ne crée pas une seule tuile à la fois car, s’il le faisait, des étiquettes seraient dupliquées, le moteur d’étiquetage n’ayant aucun moyen de savoir quelles étiquettes sont déjà présentes sur les tuiles adjacentes.

Les deux sections suivantes abordent différentes méthodes visant à limiter l’impact négatif sur les performances de la mise en cache à la demande.

Choix des cas d’utilisation de la mise en cache à la demande

L’élément le plus important à définir lors de la configuration de la mise en cache à la demande est de savoir quelles surfaces seront créées à la demande et quelles surfaces seront mises en cache au préalable. N’utilisez jamais la mise en cache à la demande pour créer l’intégralité du cache. Vous devez toujours créer au préalable des tuiles pour les surfaces de la carte susceptibles de recevoir le plus de trafic d’utilisateur. Cette précaution permet d’éviter qu’un utilisateur utilise les ressources du serveur en demandant une tuile à la demande.

Déterminer les aspects d’une carte qui plairont le plus dépend largement de l’objectif et du public de cette carte. Dans un fond de carte général, les zones peuplées, les routes, les côtes, les parcs et autres points d’intérêt ont le plus de chances d’être consultés plus souvent que les autres zones.

Les cartes thématiques (par opposition aux fonds de carte) peuvent mettre en évidence différentes tendances d’endroits visités. Par exemple, une compagnie minière utilisera de façon plus intensive les endroits de la carte où la densité de mines est plus importante. Cela peut être le cas dans des zones non peuplées ou montagneuses, qui ne présenteraient aucun intérêt pour la population générale.

Pour connaître les surfaces à mettre en cache, portez votre attention sur les modèles d’utilisation de vos cartes actuelles, qu’elles soient en ligne ou sur l’ordinateur. Vous pouvez apprendre beaucoup en observant officieusement les endroits auxquels les utilisateurs ont tendance à accéder et les entités qu’ils interrogent.

La disponibilité et la résolution des données sont également un facteur important. Si les données sont peu nombreuses, voire inexistantes, dans certaines surfaces, vous pouvez ignorer la mise en cache de ces surfaces. Même si quelqu’un requiert une tuile à la demande, son affichage ne prendra que peu de temps s’il n’y a rien à afficher.

Vos données peuvent en outre être étroitement liées à l’objectif de la carte. Par exemple, si vous travaillez avec un service de transport, assurez-vous que les surfaces présentant une forte densité de routes et de voies ferrées sont mises en cache. Les outils d’analyse spatiale tels que Densité de noyau peuvent vous aider à déterminer quelles surfaces générales comptent une forte densité d’entités intéressantes.

Une fois que vous avez déterminé les endroits que les utilisateurs visiteront le plus souvent, créez une classe d’entités qui isole ces surfaces. Référencez cette classe d’entités en exécutant l’outil Gérer des tuiles de cache de serveur de carte pour vous assurer que les tuiles sont créées uniquement dans les limites de la classe d’entités.

Vous pouvez associer plusieurs outils dans un modèle ou script pour obtenir cette classe d’entités d’endroits visités. Le modèle peut contenir différentes saisies d’entités qui seront sans doute très visitées, mettre en zone tampon les entités ou déterminer leur densité, et enfin effectuer le post-traitement du résultat pour vérifier que la classe d’entités obtenue convient au modèle de mise en cache. Vous pouvez, par exemple, utiliser l’outil de géotraitement Simplifier un polygone pour supprimer les sommets en surplus susceptibles de ralentir l’exécution des outils de mise en cache.

Plus vous isolez de surfaces visitées sur la carte, plus vous pouvez satisfaire de demandes avec les tuiles mises en cache au préalable au lieu de créer des tuiles à la demande. À grande échelle, vous pouvez n’avoir besoin de mettre en cache qu’une petite partie de la carte pour satisfaire la majeure partie des demandes d’utilisateurs. Vous pouvez décider d’utiliser le temps et l’espace disque libérés pour mettre en cache de façon stratégique des niveaux d’échelle supplémentaires.

Test et optimisation de la carte

De nombreuses organisations possèdent des cartes complexes préparées à l’origine pour des opérations de SIG bureautique. Ces cartes ont souvent besoin d’être adaptées aux temps de réponse rapides attendus par les utilisateurs du web.

Avant de modifier une carte, créez un cache de test sur une petite surface pour disposer de quelques chiffres de base. Choisissez une surface représentative de la géographie représentée dans la carte (une zone urbaine et rurale, plate et montagneuse, etc.). Notez le temps que prend la création du cache de test. Activez ensuite la mise en cache à la demande et effectuez un zoom sur une zone non mise en cache. Notez le temps que prend l’affichage des tuiles à différentes échelles. Si les performances sont acceptables à ce stade, vous n’avez pas besoin d’apporter des modifications.

Si vous souhaitez une détection avancée des couches inefficaces dans un service de carte, définissez le niveau de consignation du site ArcGIS Server sur Verbose (Commentaires). Émettez une demande d’affichage auprès du service de carte, par exemple un zoom sur un géosignet dans ArcGIS Pro. Examinez ensuite les journaux d’ArcGIS Server dans ArcGIS Server Manager et notez le temps d’affichage de chaque couche. Vous serez rapidement en mesure de dire quelles couches prennent le plus de temps. Il est conseillé de répéter cet exercice à différentes échelles mises en cache sur des surfaces aléatoires de la carte. N’oubliez pas de redéfinir le niveau de consignation sur sa précédente valeur lorsque vous avez terminé, car le niveau de consignation Verbose (Commentaires) consigne plus d’informations dans le journal que vous n’en avez besoin en règle générale.

Une fois que vous avez optimisé la carte, réalisez un autre cache de test et notez la durée de création d’une tuile à la demande. Si les performances ne vous conviennent toujours pas, vous pouvez effectuer l’une des opérations suivantes :

• Mettre en cache une plus grande surface. Cette méthode permet de réduire les chances de rencontrer une tuile à la demande. Vous pouvez essayer de limiter la mise en cache à la demande aux surfaces les plus stériles et aux plus grandes échelles uniquement, en vous assurant ainsi que peu d’entités devront être affichées simultanément.
• Réalisez un cache total. En mettant en cache toutes les tuiles, vous n’aurez pas à créer de tuiles à la demande. Cette mesure peut constituer la meilleure option si vous disposez du temps et de l’espace appropriés pour créer un cache total et que celui-ci ne sera pas souvent mis à jour. Si vous pensez que le serveur risque de connaître une défaillance pendant la mise en cache, vous pouvez programmer les tâches de mise en cache la nuit et le week-end pour créer de façon constante le cache du service jusqu’à ce qu’il soit complet. Vous pouvez également ne consacrer qu’une seule instance de service à la mise en cache tandis que d’autres instances gèrent les demandes des utilisateurs.
• Utilisez un service affiché dynamiquement. Si la création d’un cache total n’est pas faisable et si les performances sont acceptables avec un service affiché dynamiquement, vous pouvez décider d’ignorer entièrement la phase de mise en cache. Bien que cette possibilité n’offre pas les meilleures performances, les données du service de carte seront toujours actuelles.

Mise à jour de tuiles

Lorsque vous modifiez les données source du service de carte mis en cache, vous devez mettre à jour le cache pour que les utilisateurs puissent voir les changements. Si vous suivez la recommandation de mise en cache d’une surface en fonction d’une classe d’entités et de remplissage du reste du cache à la demande, vous devez faire attention à ce que les mises à jour incluent toutes les surfaces nécessaires.

Vous pouvez suivre deux stratégies pour mettre à jour votre cache lorsque vous utilisez des tuiles créées à la demande :

Supprimez toutes les tuiles qui ont été créées à la demande avant d’effectuer une mise à jour.

Si vous créez des tuiles à la demande, vous avez probablement mis en cache une certaine surface en fonction d’une classe d’entités. En règle générale, vous effectuez également la mise à jour en fonction de cette classe d’entités, et les tuiles à la demande deviennent obsolètes si vous ne les supprimez pas.

Pour supprimer les tuiles, exécutez l’option Gérer des tuiles de cache de serveur de carte en mode Supprimer des tuiles. Supprimez les tuiles à l’inverse de la classe d’entités en fonction de laquelle vous avez effectué la mise en cache. Vous pouvez utiliser les outils de mise à jour ArcGIS pour créer un polygone représentant la vue globale de la carte et y découper un trou correspondant à la surface mise en cache. Le polygone en anneau obtenu est la surface dans laquelle les tuiles doivent être supprimées. Reportez-vous à la rubrique Découper un trou dans une entité surfacique pour savoir comment découper un trou dans un polygone à l’aide de l’outil Clip (Découper) d’ArcGIS Pro.

Vous pouvez également supprimer toutes les tuiles du cache avant de commencer la mise à jour, mais cela risque d’affecter les ressources du site ArcGIS Server si le cache est volumineux.

Si vos utilisateurs se plaignent de devoir attendre qu’un endroit en particulier soit mis en cache à la demande après chaque mise à jour, ajoutez cet endroit à la surface mise en cache. Avec une mise en cache préalable judicieuse, la mise en cache à la demande ne doit survenir que peu souvent de façon aléatoire dans des zones de la carte présentant un moindre intérêt. Si les utilisateurs reviennent constamment à un endroit sur la carte, cet endroit doit être mis en cache.

Faites en sorte que les mises à jour du cache ne couvrent que les surfaces où les données ont été modifiées.

Pour ce faire, vous pouvez par exemple utiliser l’archivage des géodatabases ou un outil personnalisé pour suivre toutes les modifications depuis la dernière mise à jour, puis exporter ces surfaces modifiées dans une classe d’entités et mettre à jour les tuiles en fonction de la limite de la classe d’entités.

Si vous êtes certain que vos mises à jour ne portent que sur des surfaces qui ont été modifiées, il n’est pas nécessaire de supprimer toutes les tuiles qui ont été créées à la demande.