Explications, trucs, astuces et avertissements
Explications
Ce cluster de cache est en fait composé d’hôtes appfabric (caching services) Un des gros avantage est que les hôtes qui ne font pas partie du cluster mais interagissent avec gardent une copie locale des objets. Et cette copie est automatiquement maintenue à jour. En clair pas besoin d’implémenter un pattern lazy loading pour éviter les allers-retours sur le réseau.
Comment est-ce que ça fonctionne ? C’est assez simple. Le cluster de cache est divisé en partitions (définies par SharePoint, voir l’énumération SPDistributedCacheContainerType https://msdn.microsoft.com/en-us/library/office/microsoft.sharepoint.distributedcaching.utilities.spdistributedcachecontainertype.aspx ) Vous ne pouvez donc pas créer de partition pour votre application. Essayez de mettre en cache vos données dans une partition qui correspond à ce que vous réalisez.
Les données mises en cache peuvent également appartenir à une région. Vous pouvez créer des régions si vous en avez besoin, elles vous permettront de manipuler vos objets plus facilement.
Le cache distribué gère aussi les problématiques de locking/unlocking. Des méthodes sont fournies pour gérer les statuts de verrouillage. De la même manière vous avez aussi accès à un ensemble d’informations sur les objets en cache telles que la version, la dernière mise à jour, le statut de verrouillage, la date d’expiration de la donnée… Ceci peut s’avérer utile dans le cadre d’une utilisation avancée.
Trucs et astuces
Avantage important, ce cluster de cache n’est pas accessible que depuis le contexte IIS. Vous pouvez donc lire et/ou écrire dans le cache depuis un timerjob, un service etc. Vraiment pratique pour les scénarios de pré chargement des données.
Autre information à considérer, la nature des données mises en cache. Il faut mettre en cache les données qui sont beaucoup utilisées (et pas forcément toute les données) et/ou qui prennent beaucoup de temps à générer. Evitez de mettre de gros objet en cache, le chargement d’objets lourds sur le réseau peut ajouter beaucoup de latence, de plus vous risquez de remplir le cache rapidement. Il faut stocker des objets les plus petits possibles, si vous avez des collections d’objets importantes par exemple, essayez de restructurer les données pour les éclater, quitte à avoir à maintenir un index (ou plusieurs).
Je vous conseille personnellement de toujours attribuer une région à vos données en cache. C’est toujours utile quand on veut vider le cache pour tout recharger.
Il arrive souvent que le service de cache se mette en défaut à cause des redéploiements fréquents. Ouvrez la console sharepoint et entrez ces deux cmdlets : use-cachecluster puis restart-cachecluster. Attendez de n’avoir plus de partitions fragmentées (get-cacheclusterhealth) et vous pouvez recommencer à débugger !
Dernière astuce, je ne stocke jamais mes données typées dans le cache. Je sérialise mes données avant (en passant par un dictionnaire par exemple pour toutes les propriétés). Pourquoi ? AppFabric est parfaitement capable de stocker vos données typées. Cependant j’ai cru remarquer que quand on fait ça, il a tendance à essayer de charger votre assembly dans son contexte applicatif. C’est assez gênant sur une machine de développeur où on redéploie sans arrêt et où ce genre de comportement peut bloquer la dll et faire échouer les déploiements…
Avertissements et inconvénients
Attention, SharePoint utilise une version particulière (ancienne) d’appfabric, interdit de modifier quoi que ce soit dans la configuration des hôtes sans passer par les cmdlets SharePoint. N’essayez pas non plus de mettre à jour la version d’AppFabric, ce n’est pas supporté.
Point négatif de cette version d’app fabric, elle ne vous permet pas d’utiliser des méta-données. Prenons par exemple une donnée « carte de crédit » qui soit liée dans mon modèle relationnel à une donnée « banque » mais aussi à une donnée « utilisateur ». Pour faciliter la manipulation des cartes de crédit, je pourrais vouloir tagger chaque carte de crédit avec bank-<bankID> et user-<userID>. Ça me permettrait de remonter facilement les cartes par utilisateur et/ou par banque. Malheuresement ce n’est pas possible dans cette version d’appfabric et je suis dans ce cas de figure obligé de maintenir des index de données en cache, avec les risques que cela comporte.
Il faut bien comprendre que vous n’êtes pas le seul à pouvoir manipuler vos données en cache. Elles ont un délai d’expiration et peuvent donc « disparaitre » si le cycle de vie des données est mal géré dans votre solution. De la même manière, si le cluster vient à manquer d’espace disponible (moins de 10% de ram restant sur un des hôtes du cluster), il va se mettre à faire le ménage. Enfin, ne stockez pas de données sensibles en cache et prenne en compte le fait que pour diverses raisons, le cluster peut être indisponible mais votre solution sollicitée.
Autre inconvénient architectural, votre application repose sur un composant logiciel de plus : le cluster de cache. Si ce dernier ne fonctionne pas ou mal (parce que nos amis les admins ne font pas toujours bien leur travail :P ), votre solution ne fonctionnera plus ou plus correctement. C’est quelque chose qu’il faut prendre que compte, que ce soit dans le code ou même jusque dans la partie PRA/PCA de votre applicatif. En fonction de sa criticité vous pourrez donc laisser votre solution en défaut de fonctionnement, retourner à un mode dégradé avec un chargement des données direct depuis la source ou bien même choisir de ne pas implémenter ce cache. Tout dépend de vos contraintes. Notez que si le cluster ne fonctionne plus, de nombreuses fonctionnalités de SharePoint ne fonctionneront plus non plus ou plus lentement (social, sécurité, temps de chargement des pages…)