Cache sur les projets web

Le cache sur les projets web

L’offre applicative actuelle, qu’elle soit dans les SI internes ou dans les services offerts aux internautes, repose sur une attente élevée de performances de la part des utilisateurs. Ces derniers voulaient des sites Web performants, les ont obtenus et ils expriment dorénavant les mêmes attentes de la part de leurs applications professionnelles en ligne.
Dans cet article nous traiterons de l’un des principaux concepts clé de la performance des applications web: le Cache qui opère en maximisant la réutilisation des ressources. En plus de traiter les différents types de cache qui agissent à chaque niveau de l’architecture applicative, nous allons voir aussi un exemple pratique de cache de présentation, celui du framework Microsoft Asp.net MVC 4

La performance des applications web

Le sujet de la performance des sites web reste vaste  et ce domaine n’a pas la maturité d’autres domaines transversaux apparentés (architecture ou stockage des données). La question essentielle qui se pose lorsqu’on parle de performance est quand faut-il s’en préoccuper ?

Si cela se fait au plus tôt du point de vue du concepteur d’applications agiles, l’approche est problématique : nous risquons d’optimiser des choses inutiles et nous pouvons masquer de gros problèmes de l’application.
Le remettre à plus tard comporte aussi des risques car les coûts de réalisation des changements nécessaires peuvent être énormes.

Nous recommanderons plutôt une voie médiane : concevoir l’architecture, les structures de persistance et les algorithmes en suivant une approche de design pour la performance et ne traiter les problèmes de performance qu’au moment de passer à l’échelle. Là encore ne traiter que les « zones chaudes » qui auront été détectées au cours des itérations de développement. Cette approche sera évoquée dans de futurs articles car il y a beaucoup à dire et à partager sur ce sujet. Ici, nous nous concentrerons sur une technique de traitement a posteriori des « zones chaudes » d’une application.
Pour quoi se focaliser sur le cache dans cet article ? Il s’agit de notre conviction d’auteur que le cache est l’outil dont l’utilité marginale est la plus forte dès qu’il s’agit de maximiser les performances d’une application web. Du reste, il s’agit de l’une des techniques les plus faciles à mettre en œuvre.

Le cache ou plus exactement la mémoire-cache est un système qui stocke temporairement des résultats de requêtes et les retransmet au besoin de façon transparente afin d’accélérer les requêtes. Et par requête, nous entendons toute demande d’un client qui requiert une réponse d’un serveur.

Les systèmes de cache ont un grand avantage lorsque les améliorations de performances sont effectuées une fois que le code applicatif est écrit : ce sont souvent des solutions automatiques, transversales au projet et hautement configurables qui ne nécessitent aucun changement de code. Chaque changement sur le code d’un projet impliquant des coûts importants, on mesure aisément l’avantage de telles solutions.

Types de cache pour les projets web

Voici des types de cache que nous pouvons utiliser :

Exemple pratique pour un cache

Pour démontrer le pouvoir du cache nous allons réaliser des tests de mesure de performances sur un projet web Asp.net MVC.

Contexte

Pour tester les différents types de cache et pour avoir des valeurs qui sont le plus proche possible de la réalité nous mettons en place une application web réaliste. Nous souhaitons que l’application reprenne une requête web moyenne. En terme d’exigences, notre environnement de test répondra à ces spécifications.

Qu’est ce qu’on mesure ?

Nous nous intéresserons à l’impact des différents types de cache sur la performance du projet autour d’une seule requête web. Nous allons donc mesurer la durée de service de cette requête et obtenir un indicateur sur le nombre de requêtes transmises par seconde (débit de performance, throughput en anglais). Pour obtenir des valeurs représentatives nous faisons 100 requêtes l’une après l’autre et nous gardons la valeur moyenne du temps de réponse afin de lisser l’effet de dispersion dû aux instabilités du réseau. Pour réaliser les tests nous utilisons l’outil « ab » de la suite Apache Serveur HTTP.

Performance standard

Tout d’abord, nous mesurons la performance standard, c’est-à-dire le débit de performance de l’application sans mettre en place un type de cache en particulier. Nous prenons 5 mesures sur 100 sur un temps de test de 25 minutes. Cette performance standard s’établit à 2.75 requêtes/seconde ce qui est très faible et totalement en deçà des performances attendues par l’utilisateur le moins exigeant.

Mémoire-cache d’objets métier
Le premier type de cache que nous mettons en œuvre est le cache des objets métiers. Dans des conditions réelles, aucun objet métier ne peut résider dans le cache pendant très longtemps car l’objet métier étant dynamique et transactionnel, sa représentation en cache sera invalidée dès que l’état de l’objet aura changé. Pour produire des valeurs réalistes qui tiennent compte des invalidations, nous réalisons 3 types de tests ici, en fonction du pourcentage des opérations du cœur métier qui sont mises en cache : 100%, 75% et 50%.

Nous obtenons un débit de performance de 100 requêtes/seconde en moyenne. L’amélioration de la performance par rapport au cas de performance standard est appréciable : une croissance de plus de 3500% ! Cette amélioration n’a eu aucun impact direct dans le code car la mise en œuvre n’a requis que peu de configuration du conteneur d’injection de dépendance qui supporte une mémoire-cache pour chaque objet qu’il injecte.
La dégradation du débit de performance en fonction de la proportion d’objets en cache n’est pas linéaire, c’est encore une bonne raison pour utiliser cette technologie car même en présence d’un fort taux d’invalidation, la fraction des objets métier qui résidera encore dans le cache conduira à des performances améliorées. Parmi les raisons qui expliquent ce comportement, on peut citer le fait que les différentes opérations du cœur métier ne sont pas identiques en termes de consommation de ressources. La différence observée entre 100% et 50% est plus faible car nous avons choisi de toujours mettre en cache les opérations les plus coûteuses.

Cache d’objets métier distribué

L’une des limitations du système précédent est que la mémoire n’est pas partagée par les serveurs dans une ferme web. Dans ce type de configuration, notre système produit des résultats au niveau d’un serveur et ces résultats ne sont pas partagés sur les autres serveurs. Une solution est de mettre en œuvre un système de cache distribués, comme memcache. Le cache ne reste plus dans la mémoire mais dans une couche externe, non transactionnelle et tolérante aux ruptures du réseau. Pour notre test nous avons employé Couchebase (une implémentation JSON de memcache). Là encore, aucune modification du code applicatif n’est requise. Le framework d’injection supporte nativement le protocole de memcache.

Nous avons opté pour une configuration de 50% d’objets métiers placés en cache pour tenir compte du plus haut taux d’invalidation induit par le partage du cache entre plusieurs serveurs d’application.
Le débit de performance s’établit en moyenne à 18,3 requêtes/seconde. L’amélioration est moindre que dans le cas du cache dédié mais, dans ce cas précis, nous payons le prix de la communication réseau et de la sérialisation en JSON des objets.

Cache de présentation ASP.NET MVC

Dans ce dernier cas de test, nous utiliserons le cache standard du framework MVC de ASP.NET : le résultat complet d’une requête web est mis en cache pour une certaine période. Ce type de cache est très performant car il tire parti de son intégration avec le framework pour éviter certaines opérations coûteuses (action dans le contrôleur, recherche et exécution des vues et des vues partielles).

Les mesures indiquent un débit de performance moyen de 275 requêtes/seconde. Cette valeur est la meilleure de tous les environnements testés et s’explique par le fait que les invalidations des données manipulées dans la couche de présentation ont moins d’impact quant à leur réutilisation depuis le cache.

Ce type de cache a le plus grand impact sur la performance d’un projet moyen et est aussi facile à mettre en place et à configurer. Son seul défaut est de nécessiter une technologie hôte bien particulière (ici le framework MVC de ASP.NET). Il conviendra, pour l’architecte de solutions logicielles, donc de choisir une technologie de mise en œuvre de la couche de présentation de l’application qui propose une technologie de mémoire-cache efficace et pratique.

Cet article a été rédigé par Irinel Matei, ex expert .Net Pentalog