Utilisation du cache d’objets avec SharePoint
Cet article explique la différence entre l’utilisation du cache d’objets dans SharePoint Server 2013 en local et SharePoint dans Microsoft 365.
L’utilisation du cache d’objets dans le déploiement SharePoint a un impact négatif significatif. Toute dépendance vis-à-vis du cache d’objets dans SharePoint réduit la fiabilité de votre page.
Fonctionnement du cache d’objets SharePoint dans Microsoft 365 et SharePoint Server 2013
Lorsque SharePoint Server 2013 est hébergé localement, le client dispose de serveurs web frontaux privés qui hébergent le cache d’objets. Cela signifie que le cache est dédié à un client et n’est limité que par la quantité de mémoire disponible et allouée au cache d’objets. Étant donné qu’un seul client est servi dans le scénario local, les serveurs web frontaux ont généralement des utilisateurs qui effectuent des requêtes sur les mêmes sites à plusieurs reprises. Cela signifie que le cache est rapidement plein et reste plein des résultats de la requête de liste et des objets SharePoint que vos utilisateurs demandent régulièrement.
Par conséquent, la deuxième fois qu’un utilisateur visite une page, le temps de chargement de la page s’améliore. Après un minimum de quatre chargements de la même page, la page est mise en cache sur tous les serveurs web frontaux.
En revanche, dans SharePoint dans Microsoft 365, il y a beaucoup plus de serveurs, mais aussi beaucoup plus de sites. Chaque utilisateur peut se connecter à un serveur web frontal différent sur lequel le cache n’est pas rempli. Ou, peut-être que le cache est rempli pour un serveur, mais que l’utilisateur suivant de ce serveur web frontal demande une page à partir d’un autre site. Ou, même si l’utilisateur suivant demande la même page que lors de sa visite précédente, la charge est équilibrée vers un autre serveur web frontal qui n’a pas cette page dans son cache. Dans ce dernier cas, la mise en cache n’aide pas du tout les utilisateurs.
Dans la figure suivante, chaque point représente une page qu’un utilisateur demande et où elle a été mise en cache. Les différentes couleurs représentent différents clients qui utilisent l’infrastructure SaaS en partage.
Comme vous pouvez le voir dans le diagramme, les chances qu’un utilisateur donné accède à un serveur avec la version mise en cache de sa page sont minces. En outre, en raison du débit élevé et du fait que les serveurs sont partagés entre de nombreux sites, le cache ne dure pas longtemps, car il n’y a que beaucoup d’espace disponible pour la mise en cache.
Pour toutes ces raisons, le fait de s’appuyer sur les utilisateurs qui obtiennent des objets mis en cache n’est pas un moyen efficace de garantir une expérience utilisateur de qualité et des temps de chargement des pages dans SharePoint.
Si nous ne pouvons pas nous appuyer sur le cache d’objets pour améliorer les performances dans SharePoint, que utilisons-nous à la place ?
Étant donné que vous ne devez pas vous appuyer sur la mise en cache dans SharePoint, vous devez évaluer d’autres approches de conception pour les personnalisations SharePoint qui utilisent le cache d’objets. Cela implique d’utiliser des approches pour les problèmes de performances, qui ne reposent pas sur la mise en cache des objets afin de produire de bons résultats pour les utilisateurs. Ceci est décrit dans certains des autres articles de cette série et inclut :