Décharger le serveur avec un Cache inversé

Le cache inversé (reverse-cache) semble être bizarrement placé. Le rôle d'un cache est habituellement d'économiser de la bande passante sur le lien amont en prenant les données dans le cache au lieu de les télécharger à chaque fois que c'est possible. Or le cache inverse est situé devant le serveur d'origine, généralement dans le même LAN c'est à dire dans une configuration où économiser de la bande passante n'a aucun sens.

Décharger les serveur web

En réalité le rôle d'un cache inversé est de décharger le serveur : chaque requête servie directement par le cache inversé allège la charge du serveur : CPU plus accès disque.

Cela implique une utilisation particulière du cache en mode sticky : dès qu'une donnée est disponible dans le cache, elle doit être servie sans revalidation auprès du serveur. La raison est très simple : la validation suppose d'accéder au fichier, de lire ses caractéristiques, et même éventuellement de lire le fichier tout entier pour calculer une signature qui sert à la production d'un ETag. C'est-à-dire que valider une donnée requiert quasiment autant de ressources que de la servir.

Il est donc important que le cache ne fasse pas de revalidations ou en fasse le minimum. Ceci est obtenu en interdisant les revalidations dans la configration du cache ou en forçant une durée de fraîcheur des données stockées dans le cache.

Evidemment, les données dynamiques ou celles mises à jour fréquemment ne doivent pas être cachées en mode sticky. Le cache inversé concerne donc essentiellement voir uniquement les composants statiques du site Web ou d'eCommerce.

Dévalidation du cache

Qu'en est-il du risque de servir des données périmées ? A la différence des millions de caches des navigateurs, le cache inversé est unique et sous contrôle : il est donc possible de le purger à tout instant en particulier lors de mise à jour du site.