N° 127 - Comprendre le mécanisme des caches sur les couches d'entités hébergées
Les couches d'entités hébergées constituent un des principaux types de contenus utilisés sur ArcGIS Online. Ils permettent de diffuser des couches d'informations géographiques (ou de simples tables) dynamiques souvent exploitées à travers des cartes, des scènes et des applications web. Ces couches d'entités hébergées peuvent être de densités et de volumétries très variables, et leur accès (affichage, requête, filtrage, ...) doit rester performant quel que soit le nombre d'utilisateurs simultanés qui les exploitent. Par exemple, sur des grands événements sportifs français, ArcGIS Online a ainsi démontré sa capacité à supporter plusieurs milliers de connexion simultanées générant plusieurs centaines de millions de requêtes sur quelques jours sans aucune dégradation des performances.
Pour permettre cette scalabilité en termes de volumétrie et de nombre d'utilisateurs, Esri combine plusieurs stratégies: généralisation à la volée des géométries en fonction de l'échelle, compression des données, mais aussi un mécanisme de tuilage des requêtes et un système de caches de réponses. L'objet de cet article est d'expliquer comment est mis en oeuvre ce mécanisme de caches.
Introduction
La possibilité de mettre en cache, à différents niveaux, les réponses aux requêtes des utilisateurs sur une couche d'entité est très intéressante pour les contenus publics car elle permet de garder des performance optimum même lorsque vos cartes deviennent virales.
Avant d'aller plus loin, décrivons ce qu'est une réponse. Une réponse correspondant aux informations renvoyées par le service web de la couche d'entités à une question que vous lui avez posée. Une application cliente peut poser différents types de questions (de requêtes), mais la plus courante est de renvoyer la description des entités présente dans l'étendue actuelle de ma carte.
Les clients basés sur l'API Javascript ArcGIS ou les SDKs QArcGIS Runtime, et par extension ArcGIS Online, fonctionnent bien avec des couches d'entités de toutes tailles. Lorsque les couches d'entités comportent un petit nombre d'entités, elles peuvent être récupérées en une seule requête car la taille de la réponse est petite. Pour les couches plus grandes, les entités sont demandées à l'aide de requêtes tuilées (fractionnement de la requête en plusieurs requêtes spatiales plus petites). Ces requêtes de tuiles sont définies de telle sorte qu'elles soient cohérentes, même entre différents utilisateurs et applications. Cette cohérence permet à ces réponses d'être mises en cache une fois sur le serveur et partagées entre tous les utilisateurs. Dans les deux cas (simple ou tuilé), ces requêtes peuvent être mise en cache dans l'application cliente (navigateur par exemple). Les requêtes de tuiles utilisent également la quantification pour améliorer les performances, mais c'est un sujet à part entière que je traiterai dans un autre article de blog.
Étant donné qu'ArcGIS Online utilise la mise en cache des réponses côté serveur, lorsque plusieurs utilisateurs demandent les mêmes informations, ce cache est alors utilisé. Cela libère les ressources à la fois sur le serveur et la base de données sous-jacente, permettant aux couches d'entités de s'étendre à des millions d'utilisateurs et de clients sans avoir à générer explicitement des tuiles à l'avance (ce qu'ArcGIS Online prend également en charge lorsque vous en avez besoin avec les couches de tuiles raster ou les couches de tuiles vectorielles). Bien entendu, les réponses mises en cache par le serveur sont automatiquement invalidées lorsque les données sont modifiées. Ceci garantit que les applications clientes utilisant la couche disposent toujours des informations les plus récentes.
On peut donc résumer cela de la manière suivante: "ArcGIS Online utilise les requêtes de tuiles et la mise en cache des réponses de manière stratégique pour optimiser les performances et réduire la charge".
Pour certains d'entre vous, le savoir sera suffisant. Pour les plus geeks, je poursuis par une description un peu plus poussée pour comprendre tous les composants mis en oeuvre pour obtenir des couches d'entités performantes.
Mise en cache côté client: votre cache personnel dans votre navigateur
La mise en cache côté client constitue votre propre cache des réponses renvoyées par le serveur, géré dans votre navigateur web. Lorsque vous interrogez une couche d'entités, le service d'entités répond avec un ensemble d'entités qui est téléchargé et stocké dans le cache de votre navigateur. Lorsque vous parcourez la carte ou effectuez un zoom avant ou arrière, le navigateur utilise les entités téléchargées dans le cache du navigateur chaque fois que possible afin d'éviter d'avoir à télécharger à nouveau ces entités à chaque fois que l'étendue de la carte change.
Ce cache de navigateur a cependant une durée de vie limitée. Si vous parcourez vos données alors qu'elles ont été modifiées, pas de soucis, le navigateur demande toujours au serveur si quelque chose a changé depuis la dernière requête. Si c'est le cas, le navigateur obtient les nouvelles entités et met à jour son cache en conséquence. Cela garantit que ce que vous voyez sur la carte est à jour et réduit la charge sur votre ordinateur et sur la plateforme Cloud ArcGIS Online. Ce cache de navigateur persiste uniquement sur le poste client et n'est stocké nulle part ailleurs. Par conséquent, ce cache ne profite qu'à vous. Cela nous amène au CDN dont l'objectif est d'améliorer l'expérience de chacun.
CDN: un cache pour tous, partout
Les réseaux de diffusion de contenu (Content Delivery Network ou CDN pour faire court), sont l'épine dorsale d'un Internet rapide. Pour les couches d'entités hébergées et partagées publiquement, le CDN agit de manière similaire à la mise en cache côté client, mais avec quelques différences. Tout d'abord, le cache de réponse CDN est réutilisé par toute personne utilisant la couche et envoyant la même requête, afin que tout le monde en profite, pas seulement vous. Deuxièmement, le CDN est distribué dans le monde entier et le cache est mis en miroir, ce qui signifie que même si les serveurs hébergeant les données sont à l'autre bout du monde, le cache est probablement beaucoup plus proche physiquement de vous. Ainsi, en plus d'être mises en cache, les données ont moins de noeud à parcourir sur Internet pour atteindre votre poste, donc elles sont plus rapides à télécharger.
 |
| Copyright DigitalOcean |
Mise en cache côté serveur: partagée et stockée dans ArcGIS Online
Comme mentionné précédemment dans cet article, seules les couches partagées publiquement utilisent le CDN, les couches privées (partagées au sein de votre organisation) n'utilisent pas le cache de réponse CDN. Ceci est logique car la sécurité de vos données implique que vos données privées ne soient jamais mises en cache sur des serveurs externes comme ceux des CDN. La mise en cache côté serveur permet de mettre en cache les réponses aux requêtes de tuiles dans ArcGIS Online afin que les autres utilisateurs de votre organisation et les utilisateurs publics puissent réutiliser le cache lorsque les caches du navigateur et du CDN ne peuvent pas être utilisés. Ce cache est partagé entre tous les utilisateurs autorisés à accéder à la couche. Il est maintenu en interne dans le cadre de l'infrastructure d'ArcGIS Online. En conséquence, les requêtes renvoient leur réponse plus rapidement, mettent moins de charge sur les bases de données sous-jacentes et assurent le bon fonctionnement de l'ensemble lors du passage à un nombre d'utilisateurs plus important, même sous une charge élevée. À mesure que vos données changent, le cache coté serveur est invalidé puis rafraîchi pour garantir aux utilisateurs qu'ils accèdent à la données la plus récente.
Récapitulatif: mise en cache des réponses en bref
Lorsque vous assemblez toutes les méthodes de mise en cache pour les couches d'entités hébergées, le flux de travail ressemble à ceci:
Bonne route sur ArcGIS Online !
