Prélude
J’étais parti pour faire uniquement un article, mais j’ai constaté en cours de route qu’il y avait plein de choses à expliquer. De plus je suis bavard, ça ne m’aide pas forcément. J’ai donc opté pour une série d’articles (3). Un article sera publié tous les deux jours à compter d’aujourd’hui. L’exemple de code sera fourni avec le dernier article, ça vous oblige à lire jusqu’à la fin ;-) Bonne lecture, et n’hésitez pas à commenter.
Introduction
La performance est une problématique récurrente lorsque l’on conçoit des solutions pour SharePoint.
C’est un vaste sujet que plusieurs articles ne suffiraient pas à couvrir, aussi je vais me concentrer sur un des leviers qui peut vous aider à améliorer la performance : la mise en cache.
SharePoint 2010 fournissait déjà un certain nombre de mécanismes de mise en cache. Un résumé assez intéressant est présent à cette adresse.
Pour récapituler rapidement voici les mécanismes de mise en cache que vous aviez jusqu’alors à disposition :
Cache de sortie (output cache) : permet la mise en cache du résultat HTML généré pour les sites de publication, côté client et serveur.
Cache objet : met en cache des objets et requêtes SharePoint afin d’y accéder plus rapidement la fois suivante.
BLOB cache : met en cache des fichiers volumineux (images, vidéos…) sur le disque local de la machine web frontale (wfe).
Cache ASP.NET : permet de cacher des objets en mémoire IIS. Les choses se compliquent lorsque l’on doit assurer une consistance des données entre plusieurs serveurs frontaux.
Cache BDC : lorsque l’on accède à un service externe, permet de diminuer les allers/retours en cachant certain des appels.
Certains d’entre nous utilisaient aussi d’autres mécanismes :
Cache dans la mémoire IIS (références statiques principalement), pose toujours un problème de consistance sur les environnements distribués.
Cache dans la session, problèmes de volumétrie, accessible uniquement pour une session donnée (les données ne peuvent être partagées), problème de consistance (pouvant être diminué avec le ASP.NET Session State Provider).
Cache dans le contexte http : dure uniquement le temps de la requête, souvent utilisé pour cacher des données entre plusieurs composants d’une même page.
SharePoint 2013 arrive avec une nouveauté importante : le service de cache distribué. De nombreux administrateurs en ont déjà parlé (et se sont plaints à son propos, moi le premier)
Ce nouveau service de cache représente une réelle nouveauté pour les applicatifs qui sont gourmands en ressources.
Je l’ai déjà évoqué dans mon précédent article sur le sujet mais le principe est de constituer un cluster de cache au travers de la ferme SharePoint. Sa topologie peut varier d’un nœud sur l’unique serveur de la ferme à plusieurs hôtes dédiés dans le cadre d’installation plus importantes.
