Le cache c'est la vie ! Sans lui AG ne serait que brouette rhumatisante et utilisateurs barbés de devoir attendre autant de temps entre chaque page. Cependant les problèmes commencent dès que vous gérez une ferme de sites ou des applications hétérogènes qui doivent partager les mêmes données en cache. Mais rassurez-vous AppFabric est là pour ça.
Tout d'abord commençons par préciser que Windows Server AppFabric est le regroupement de deux projets Microsoft "Velocity" et "Dublin" qui sont devenus respectivement Caching Services et Hosting Services.
Hosting Services est dédié à améliorer le support pour l'hébergement de services WCF, en particulier ceux utilisant Workflow Fondation. Bien qu'intéressant ce module ne nous intéressera pas pour cet article.
En revanche Caching Services est la solution Microsoft pour répondre aux besoins d'infrastructure pour la mise en place de cache distribuée. Malheureusement vous l'aurez sans doute deviné mais cette solution n'est prévue que pour fonctionner avec les autres produits Microsoft, amis javaïstes et phpïstes passez votre chemin...
Cluster de cache Kézako ?
Un cluster est une entité logique du réseau regroupant plusieurs machines faisant le même travail. L'idée est que les applicatifs ne connaissent que la tête du cluster, cette dernière se chargeant de rediriger la demande sur la machine la plus appropriée et renvoyer l'information. L'avantage est que l'on peut ajouter ou retirer des machines au cluster tout en restant transparent pour les applicatifs consommateurs.
C'est la même idée qu'un répartiteur de charge pour les serveurs web sauf qu'ici il s'agit de renvoyer des informations en cache plutôt que des pages web. La fonction première de Caching Services est donc de pouvoir mettre en place ce cluster de cache mais pas que !
Et je peux faire quoi d'autre avec mon cache ?
Outre l'architecture physique au travers du cluster, Caching Services vous permet également d'avoir une segmentation logique de votre cache sur deux niveaux.
Le premier niveau regroupe les caches nommés, configurés lors de la création du cluster. Si vous gérez une ferme de cache dont vous proposez les services à des clients différents, c'est une bonne idée de créer un cache nommé par client afin que chacun reste séparé des autres.
Le second niveau regroupe les régions au sein d'un cache nommé. Cette fois c'est l'applicatif qui a la charge de les créer ce qui lui permet d'avoir son propre découpage logique, particulièrement pratique pour pouvoir faire expirer en même temps les éléments d'un même groupe. A noter que ce second niveau est facultatif.
Il est également possible d'ajouter une ou plusieurs étiquettes à un objet mis en cache afin de pouvoir faire des recherches d'objets par étiquette via les API de Caching Services. L'inconvénient est qu'il faut placer l'objet à l'intérieur d'une région pour pouvoir lui adjoindre des étiquettes.
Outre les fonctionnalités d'ajout, récupération et retrait d'un objet en cache via une clé ainsi qu'une expiration absolue (mais pas glissante), Caching Services propose un ensemble de notifications assez complet auquel peut s'abonner une application le cache. Le système de dépendance introduit par "HTTP Cache" peut ici être reproduit par les régions, à ceci prêt que c'est à l'application de déterminer quand faire expirer tous les objets d'une région et non en scrutant si un fichier a été modifié.
Les API de Caching Services propose également des solutions pour gérer des mécanismes de verrouillage optimistes et pessimistes des objets mis en cache.
Enfin les applicatifs consommateurs peuvent également activer un cache client qui stocke localement les objets venant du cluster et ce de manière transparente... ou presque car un objet en cache local est du coup coupé de sa version sur le cluster qui peut éventuellement être amenée à être modifié.
Le "mais"
Parce que évidemment il y a un "mais".
Ici le problème n'est pas vraiment Caching Services qui remplit son rôle de mettre en place le cluster et proposer de nombreuses API et fonctionnalités pour interroger le cache. Non le problème est que AppFabric arrive bien tardivement dans un écosystème de sites web utilisant massivement "HTTP Cache" qui était de toute façon la seulement façon de faire jusqu'à présent.
Cela ne serait pas problématique si AppFabric pouvait remplacer silencieusement HTTP Cache sans pour autant modifier le code mais ce n'est pas le cas. Utiliser AppFabric requiert d'utiliser un jeu d'objets et de méthodes complètement différents de ce que l'on utilisait jusqu'à présent.
Pire encore, avec le Framework .NET 4.0 une classe abstraite ObjetCache est apparue avec une implémentation, MemoryCache, avec pour objectif de servir de base pour toute les formes d'implémentation de cache sauf que outre le fait de ne pas supporter non plus "HTTP Cache", AppFabric non plus ne part pas de cette base pour son implémentation, un comble !
Néanmoins
Si jusqu'à présent vous n'utilisiez que Output Cache ou la session alors vous êtes plutôt chanceux car pour le coup AppFabric vient avec un provider pour chacun des deux modules ce qui fait que cette fois l'utilisation d'AppFabric est vraiment transparente sur ces fonctionnalités là tout en amenant des avantages comme la conservation des sessions en cas de recyclage des données ou bien la mutualisation des rendus entre les serveurs web.
En outre la sécurité n'a pas été oubliée avec la possibilité de restreindre l'accès au cache qu'à certains comptes utilisateurs (i.e. l'identité du pool d'application de votre site web). De plus les données échangées peuvent être signées et/ou cryptées (les deux par défaut).
En outre si vos serveurs ont l'option "haute-disponibilité", les données en cache se répliqueront sur les différents serveurs afin de minimiser le risque d'indisponibilité des données en cas de défaillance d'un des serveurs du cluster.
Encore une discuSSion difficile à comprendre je suis maudit !!
Rassures-toi, je pense que tu ne seras pas le seul, cet article s'adresse avant tout aux développeurs informatiques. Mais c'est cela qui est bien sur AG c'est qu'on publier des articles sur n'importe quel sujet, la condition étant de bien les rédiger
Autant je vois tout à fait l'intérêt d'un CDN ou d'un hébergement Cloud, autant j'ai plus de mal avec un service de cache distant. Le but du cache est d'améliorer les performances, or les requêtes HTTP sont très coûteuses en temps. D'autre part, les applications web sont de plus en plus personnalisables, ce qui rend la mise en cache d'autant plus difficile. Quitte à avoir des requêtes HTTP supplémentaires, autant opter pour le chargement en différé via Ajax, non ?
Côté cache, je suis plus favorable à des choses type memcache, même si je suis bien conscient que dans un environnement distribué ça devient plus complexe à gérer. En même temps, centraliser la gestion du cache dans un environnement distribué, ça n'a pas de sens non plus, bref.
Tout ça pour dire que je suis très circonspect par rapport à cette solution, à moins que je ne sois complètement dépassé techniquement, ce qui est possible aussi.
Mmmh je pense que tu te méprends sur l'utilisation de AppFabric. L'idée n'est pas répondre à "je suis un fournisseur de cache pour n'importe qui sur la planète" l'idée est bien de répondre à "je veux mettre un cache distribué pour mon application". Ce qui signifie que c'est charge à toi de placer ton cluster de cache pas trop "loin" de tes machines applicatives évidemment.
Comme ne cesse de me le répéter mon architecte, les services WCF ne se limitent pas aux services Web et pas non plus au protocole HTTP. Ainsi tu peux très bien faire de la communication TCP avec ton cluster "distant" ou bien carrément installer le service sur tes machines applicatives auquel cas ce sera Named Pipe (partage de mémoire) qui sera utilisé, à peu près comme un cache embarqué avec l'application.
Par ailleurs le modèle de sécurité par compte windows implique très fortement que toutes les machines soient dans le même Active Directory de toutes façon.
Effectivement, vu comme ça, je comprends mieux l'intérêt
Tu te demandais si le référencement marchait sur n'importe lequel des articles postés sur AG, et bien j'ai une réponse. Je viens de chercher "AppFabric" sur Google avec uniquement les résultats en français, et l'article apparaît en bas de deuxième page, après les pages msdn.com et développez.com.
Moi je dis pas mal