Skip to main content

Dernière partie de cache cache avec l’AppFabric le 2/04/2016

Cela fera déjà quelques années que l'on se pose des questions sur l'avenir de l'AppFabric. L'AppFabric n'avait presque pas évolué entre ses versions 1.0 et 1.1. Il y a quelques mois, l'AppFabric 1.1 était annoncée comme compatible avec Windows 2012 R2. Mais aucune nouvelle version n'était publiée.

Depuis le 3 avril dernier, la situation est enfin claire : fin de support le 2 avril 2016 ( Microsoft AppFabric 1.1 for Windows Server Ends Support 4/2/2016 ).

Workflow Foundation et WCF vont souffrir de la disparition de ce produit qui leur apportait dans de facilités. Comme le dit si bien l'équipe AppFrabric sur son blog, il a y des solutions de remplacement possibles pour le Cache, le Hosting. Pour le monitoring et la gestion des services, il faudra monter ses propres solutions. Ayant déjà monté ce type de solution pour des projets personnels, je ne me fais pas de soucis, on peut y arriver sans monter une usine à gaz.

Étrangement, c'est au sujet des solutions de cache que je tiens à mettre en garde les utilisateurs d'AppFabric (ou d'autres produits). Avec les temps, je me suis rendu compte que l'AppFabric n'était pas toujours utilisée à bon escient. Son service de cache avait pour vocation première de fournir un cache distribué entre les serveurs IIS d'une ferme. Avec un seul serveur, le cache était souvent contre performant.

 

Demain, si vous devez choisir une nouvelle solution de cache, regardez de plus près votre besoin parmi les 4 situations les plus courantes.

 

1. Cache partagé : Vous devez charger des objets et fournir un cache de ceux-ci qui soit synchro pour tous vos IIS

Redis est prometteur. Cependant sa dernière version n'est pas encore supportée par Windows Server, et toutes les fonctionnalités n'y sont pas encore (mais ça va venir).

Les puristes seront tentés d'utiliser la version Linux. Attention, à ne pas être dans la contreperformance. Le cache n'étant plus disponible localement sur votre serveur IIS, il devra passer par le réseau. Il faudrait mieux vérifier que le jeu en vaut bien la chandelle avant de se lancer. Pour les futurs projet .net Core, il est peut-être un peu trop tôt pour se faire un avis.

 

2. Cache applicatif non partagé : Vous devez charger des objets uniquement pour le serveur local

La simple classe Cache de System.Web.Caching peut certainement faire l'affaire.

https://msdn.microsoft.com/fr-fr/library/6hbbsfk6(v=vs.100).aspx

 

3. Cache de pages web dynamique : Vous devez mettre en cache des pages ASP .net

Que vous soyez sur du WebForm ou sur du MVC, ASP .net a tout l'outillage pour répondre à votre besoin (sans rien ajouter). De plus, rien ne vous empêche d'utiliser les bonnes vielles entêtes http et metas pour demander à vos clients d'utiliser le cache de leurs navigateurs.

https://msdn.microsoft.com/fr-fr/library/06bh14hk(v=vs.100).aspx

https://technet.microsoft.com/en-us/library/dd239248(WS.10).aspx

 

4. Cache de pages web ou contenu statique : Vous devez mettre en cache des pages HTML, des fichiers ou des images

IIS étant votre ami, il dispose déjà de tout ce dont il faut pour gérer un cache des contenus qu'il sert (statique comme dynamique). Cela se trouve ici :

https://technet.microsoft.com/en-us/library/cc732475(v=ws.10).aspx

Jérémy Jeanson

Comments

You have to be logged in to comment this post.

Cookies Cookie Policy

This website uses cookies and similar technologies to allow us to promote our services and enhance your browsing experience. If you continue to use this website you agree to our use of cookies.