Couches d'entités hébergées évolutives dans ArcGIS Online : Requêtes de tuiles et mise en cache des réponses

KellyGerrow

<\/HEAD>

Découvrez ce Blog ArcGIS<\/A> par Paul Barker<\/A><\/P>

<\/P>

Contexte<\/H2>Les couches d'entités hébergées existent sous toutes les formes et tailles ; certaines commencent grandes, d'autres grandissent au fil du temps à mesure que les données sont mises à jour. Quelle que soit leur origine, il est important que les ensembles de données restent performants, ce qui m'amène au sujet du blog d'aujourd'hui : la mise en cache des réponses.  L'équipe du service d'entités hébergées a travaillé dur lors des dernières versions pour mettre en place tous les éléments nécessaires à la mise en cache des réponses.   La mise en cache des réponses peut sembler un peu ennuyeuse à première vue, mais c'est assez excitant car elle permet aux couches d'entités hébergées de s'adapter même lorsque vos cartes deviennent virales.<\/P>Avant de plonger plus loin, parlons de ce qu'est une réponse.  Une réponse est simplement la réponse de la couche d'entités à une question que vous lui avez posée.  Bien que vous puissiez poser de nombreuses questions, la plus courante est : Quelles entités se trouvent dans la carte que je regarde ?<\/P>Les clients ArcGIS Javascript API, et par extension ArcGIS Online, fonctionnent bien avec des couches de toutes tailles.  Lorsque les couches d'entités ont un petit nombre d'entités, elles peuvent être récupérées en une seule requête car la réponse de la couche d'entités est petite. Pour les couches plus grandes, les entités sont demandées via des requêtes en tuiles (divisant la requête en plusieurs requêtes spatiales plus petites). Les requêtes en tuiles ont l'avantage supplémentaire d'être cohérentes, même entre différents utilisateurs et applications.  Cette cohérence permet que ces réponses soient mises en cache une fois sur le serveur et partagées entre tous les utilisateurs. Dans les deux cas (simple ou en tuiles), ces requêtes peuvent également être mises en cache côté client.  Les requêtes en tuiles utilisent également la quantification pour améliorer les performances mais c'est un sujet à part entière que nous garderons pour un autre article de blog.<\/P>Parce qu'ArcGIS Online utilise la mise en cache des réponses côté serveur lorsque plusieurs utilisateurs demandent la même information, ce cache entre en jeu.  Cela libère les ressources à la fois sur le serveur et sur la base de données sous-jacente, permettant aux couches d'entités de s'étendre à des millions d'utilisateurs et clients sans avoir besoin de générer explicitement des tuiles à l'avance (ce que ArcGIS Online supporte aussi quand vous en avez besoin).  Ces réponses mises en cache par le serveur sont automatiquement invalidées lorsque les données sont modifiées.  Cela garantit que les clients utilisant la couche obtiennent toujours les informations les plus récentes.<\/P>Pour beaucoup d'entre vous, l'histoire simple est : 1ArcGIS Online utilise stratégiquement les requêtes de tuiles et la mise en cache des réponses pour optimiser les performances et réduire la charge.7  Pour certains, savoir cela suffit.  Mais pour les géo-geeks plus curieux, voici une plongée plus profonde sous le capot pour comprendre toutes les pièces mobiles qui fonctionnent en harmonie pour fournir des couches d'entités performantes.<\/P>Mise en cache côté client : Votre cache personnel dans votre navigateur<\/H2>La mise en cache côté client est comme votre propre cache personnel des réponses du serveur, géré par 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 déplacez la carte ou effectuez un zoom avant ou arrière, le navigateur utilise ces entités téléchargées dans le cache du navigateur chaque fois que possible afin d'éviter de devoir retélécharger les entités à chaque changement de vue de la carte.<\/P>Cependant, ce cache du navigateur a une durée de vie limitée. Si vous naviguez dans vos données pendant qu'elles sont modifiées, le navigateur demande aux serveurs si quelque chose a changé depuis la dernière fois qu'il a interrogé. Si oui, le navigateur récupère les nouvelles entités et met à jour son cache en conséquence.  Cela garantit que ce que vous voyez sur la carte est actuel et réduit la charge sur votre ordinateur et ArcGIS Online.  Ce cache du navigateur ne persiste que côté client et n'est stocké nulle part ailleurs. Par conséquent, cela ne bénéficie qu'à vous et n'accélérera pas l'expérience des autres utilisateurs.   Cela nous amène au CDN (Content Delivery Network).  Son objectif est d'améliorer l'expérience pour tout le monde.<\/P>CDN : Un cache pour tous, partout<\/H2>Les réseaux de diffusion de contenu, ou CDN pour faire court, sont l'épine dorsale d'un internet rapide.  Pour les couches d'entités hébergées partagées publiquement, le CDN agit de manière similaire à la mise en cache côté client mais avec quelques différences. Premièrement, le cache des réponses du CDN est réutilisé par toute personne utilisant la couche et envoyant la même requête, donc tout le monde en bénéficie, pas seulement vous.  Deuxièmement, le CDN est distribué partout dans le monde et le cache est dupliqué, ce qui signifie que même si les serveurs hébergeant les données sont à l'autre bout du monde, le cache est très probablement beaucoup plus proche de vous.  Ainsi, en plus d'être mis en cache, les données effectuent moins de sauts sur internet pour vous atteindre donc elles se téléchargent plus rapidement.<\/P>Mise en cache côté serveur : Partagée et stockée dans ArcGIS Online<\/H2>Comme mentionné dans la section précédente de cet article, seules les couches partagées publiquement utilisent le CDN, donc les couches partagées au sein de votre organisation n'utilisent pas le cache des réponses du CDN.  Cela garantit que vos données privées ne sont pas mises en cache sur des serveurs externes dans le monde entier.  La mise en cache côté serveur met en cache les réponses aux requêtes de tuiles au sein d'ArcGIS Online afin que d'autres utilisateurs dans votre organisation et le public puissent réutiliser ce cache lorsque le cache du navigateur et le CDN ne peuvent pas être utilisés.  Ce cache est partagé entre tous les utilisateurs autorisés et maintenu en interne dans l'infrastructure d'ArcGIS Online.  En conséquence, les requêtes reviennent rapidement, sollicitent moins les bases de données sous-jacentes et maintiennent tout fluide à grande échelle même sous forte charge.  Au fur et à mesure que vos données changent, le cache des tuiles d'entités est invalidé pour garantir que les clients utilisant la couche voient toujours l'information la plus récente.<\/P>Conclusion : La mise en cache des réponses en résumé<\/H2>
Lorsque vous combinez toutes les méthodes de mise en cache pour les couches d'entités hébergées , le flux ressemble à ceci:<\/P><\ /A ><\ /P ><\ /BODY ><\ /HTML >

DavidRunneals4

Just curious if anyone has noticed an issue of data sticking around in ArcGIS Online COTS map viewer/web app builder/etc when the feature service is empty.

After issuing the truncate command (Truncate (Feature Layer)—ArcGIS REST API: Services Directory | ArcGIS for Developers) the database is empty and a query to the feature service returns a count of 0, I have noticed that the data seems to be sticking around in the ArcGIS Online COTS map viewers/web app builders/op dashboards. Maybe it's a bug but figured I'd ask and see if anyone has seen this issue pop up when viewing apps that have hosted feature layers with no data in them.