Cache

1. A.ETTARROUZI
Cache 1

2. Plan de la présentation 2
• Background
• Type de caches
• Cache de données
• Cache distribué
• Cache répliqué
• EhCache
• MemCached
• Terracotta

3. C’est quoi un cache? 3

4. Constats 4
 Le point de vue classique suppose que la mémoire est rare et chère
 La mémoire ne coute pas cher, c’est la vision moderne
 Le cache est devenu un élément important dans les applications d’aujourd’hui
 L’accès à la donnée est simplifié par la POO et les caches
 Accéder plus rapidement à la copie que d’accéder plus lentement à la ressource
 On parle de durée de vie des objets
 Eviter la répétition des appels coûteux
 Possible perte de la donnée
 Un cache est transparent pour les développements
 Une stratégie de cache doit être bien définie

5. Vue d’ensemble 5

6. Cache passif (Push) 6
 c’est la source qui pousse la
copie vers le mécanisme du
cache
Le cache passif (mode push) implique un
mécanisme d’abonnement à l’événement
du changement de la source auprès de
cette dernière. Dans ce cas de figure, le
cache reçoit une copie de la totalité de
l’ensemble du contenu.

7. Cache actif (Pull) 7
 C’est le mécanisme du cache
qui va retirer une copie de la
source
c’est le dispositif de cache qui va
chercher une copie de l’original
auprès de sa source (disque,
réseau, serveur…)

8. Cache en JAVA 8
 Un simple cache est incarné par
une sorte d’objet de type HashMap
(collection de type Map) géré
manuellement via un mécanisme de
clé valeur pour accéder plus
rapidement aux données (issues de
bases de données relationnelles,
résultats d’appels de Web
Services…etc.).

9. Positionnement d’un cache 9
Cache navigateur
Un cache de données
se positionne
généralement entre une
application et la gestion
des données.
Cache de données
Un cache navigateur
se positionne du côté
du client.

10. MRU & LRU 10
Le principe qui se base sur la
conservation en mémoire des
contenus les plus récemment
utilisés s’appelle MRU (Most
Recently Used).
Les contenus non utilisés depuis
une longue durée (Least Recently
Used) sont tout simplement
abandonnés.

11. Hit ratio % 11
Le hit ratio = pourcentage des pages
servies par le cache.
Plus la mémoire allouée au cache
est élevée, plus ce pourcentage hit
ratio augmente.
L’objectif est d’atteindre 100% de hit
ratio, le cache contient la totalité des
contenus.

12. Cache HTTP 12
 Un cache http est géré par
un gestionnaire qui se
situe devant le serveur
http
Le cache serveur est
partagé par tous les
clients

13. Données 13
 Modèle ancien : un client envoie
directement des demandes
d’obtention de l’information
auprès du système de gestion de
base de données (SGBD).
Les secours se font sur des supports
magnétiques déconnectés.

14. Données 14
 Modèle classique : une couche de
persistance des objets en relationnel
est introduite entre la couche
applicative et celle des données ; les
objets sont construits à partir des
données en provenance du système de
gestion de base de données et vice-
versa. Le dispositif de cache est bien
entre les deux couches. L’application
travaille sur les objets fournit par la
couche du mapping objet relationnel. Les secours se font sur des supports
magnétiques déconnectés.

15. Données 15
 Modèle moderne : le cache joue
le rôle de gestionnaire primaire
de données.
 la gestion des données en
mémoire au niveau du cache
permet un accès rapide à toutes
les données à tout moment sauf
dans les cas de situations de
transitions par exemple.

16. Cache distribué 16
 Un cache distribué offre la possibilité de lancer plusieurs
instances de cache sur plusieurs serveurs.
 Les serveurs se répartissent le travail selon un
mécanisme transparent.
 L’instanciation multiple de ces instances de cache ne se
fait pas aléatoirement mais selon le besoin,
 Une nouvelle instance n’est créée que si l’ancienne
instance est saturée.
 L’objectif de la mise en place d’un cache distribué est
d’atteindre une haute performance et d’avoir une large
marge d’extensibilité.
 Comme une base de données, un cache distribué reçoit
les requêtes des applications et renvoie des réponses.

17. Cache répliqué 17
Le principe d’un cache répliqué se base
sur un mécanisme de réplication de
chaque objet sur les différentes instances
du cache, ces dernières échangent des
messages entre elles.
Une modification d’un objet sur une
instance donnée implique la mise à jour
de ses copies sur les autres instances du
cache répliqué.

18. EhCache 18
Une solution libre qui fait partie de la famille de ces frameworks de cache.
Se décompose en trois items :
 Elements : est un élément composé d’une clé et une valeur, cette valeur représente
un objet sérialisable.
 Manager : est un gestionnaire qui gère les caches et leurs cycles de vies.
 Cache : est l’objet central du framework, il est responsable de la gestion des
éléments.

19. EhCache 19
EhCache peut être implémenté selon trois approches :
 La première approche, dite standalone, consiste à tenir l’ensemble des
données du cache au niveau du nœud de l’application.
 La seconde approche, dite distribuée, consiste à retenir l’ensemble des
données au niveau de la couche du serveur Terracotta et de garde un sous-
ensemble des données récemment utilisées au niveau du nœud de chaque
application.
 La troisième approche, dite répliquée, consiste à mettre une copie de
l’ensemble des données dans chaque nœud d’application.

20. EhCache 20
EhCache supporte les patterns suivants :
 cache-aside (or direct manipulation)
 cache-as-sor (a combination of read-
through and write-through or write-
behind patterns)
 read-through / write-through
 write-behind (or write-back).

21. EhCache 21
 Cache-aside : l’accès direct à la donnée se fait dans un premier temps au niveau
du cache sinon le code de l’application récupère la donnée du système de
stockage et la stocke dans le cache avant de la retourner. Le cache est
synchronisé avec le système de stockage quand une donnée est écrite dans le
cache.
 Cache-as-sor : dans cette approche, la lecture et l’écriture de la donnée sont au
niveau du cache lui-même et non au niveau applicatif. Cette approche possède
des avantages et des inconvénients.

22. EhCache 22
 Write-behind : avec ce motif, le timing de l’écriture de la donnée est différent ; le
write-behind le fait avec un delta de temps, ce qui cause une exécution de
l’écriture de la donnée qui se fait en dehors de la transaction principale. Cette
conséquence implique la création d’une nouvelle transaction.
 Read-through : en se basant sur le motif read-through et lors de l’écriture de la
donnée, le code applicatif se base sur la même approche qu’avec le motif
cache-aside en rajoutant une implémentation de l’interface CacheWriter ;
l’écriture de la donnée se fait dans le même thread d’exécution.

23. Memcached 23
Développé à l’origine par Brad Fitzpatrick for LiveJournal en
2003.
Un système libre et open source de gestion de haute
performance des objets en cache en mémoire.
Propose une interface de programmation compatible avec la
plupart des langages de programmation du marché (Wikipedia,
Twitter et Flickr utilisent Memcached).
Permet d’orchestrer le besoin en mémoire et de bien l’utiliser.
Tous les serveurs ont accès au même espace mémoire combiné.
Garantit une évolutivité du système.
Assure une gestion de données en grande quantité d’une façon
plus facile et simple.

24. Terracotta 24
 Terracotta Cluster est un produit commercial qui permet de clustériser des
machines virtuelles Java ; l’exécution d’une application se fait sur différents
serveurs en se basant sur la manipulation du bytecode JAVA au chargement du
code dans la JVM, cette manipulation garantit les mécanismes de base de JAVA
comme le passage par référence, l’orchestration des threads d’exécution ou encore
le ramasse-miette. Un cas typique de son utilisation est celui des caches
distribuées.
 Terracotta assure une indépendance du code applicatif par rapport à
l’architecture répartie ; la « clustérisation » n’est pas codée et la propagation
d’une application au travers des JVM se fait à l’exécution, on dit que la
« clustérisation » se fait au niveau de la couche JVM

25. Terracotta 25
L’ensemble Terracotta englobe deux types de
composants :
 Le composant Serveur Terracotta : la définition
de multiples serveurs est possible dont un
serveur est principal. Les clients se connectent à
un serveur actif, si ce dernier n’est plus
disponible les clients se connectent à un autre
serveur en interrogeant les serveurs dans
l’ordre.
 Le composant Client Terracotta : Un serveur
machine hébergeant une application JAVA
clustérisée est considéré comme un client
Terracotta.

26. Mesurer 26
La performance d’un cache peut être mesurée par :
Le nombre de requêtes traitées par seconde
Le nombre d’instances de serveurs de cache
La taille de la mémoire mise en jeux
La volumétrie des données à manipuler
La vitesse de réponse
Le temps de traitement

27. Conclusion 27
 Aujourd’hui, il est très simple et facile de mettre en place un cache surtout que la plupart des
caches fonctionnent de la même manière ; on cherche la donnée au niveau du cache et non au
niveau de sa source. La gestion des données en grande quantité est plus facile.
 Mais il y a de nombreuses problématiques qui apparaissent au niveau de la mise en place d’un
cache car si ce dernier vise à augmenter les performances d’une manière considérable, son
mauvais positionnement et sa mauvaise configuration conduisent à des résultats non souhaités.
 L’objectif principal derrière l’idée d’utiliser un cache est de pouvoir contribuer à la haute
disponibilité et d’augmenter les performances des applications et des traitements mais le fait
d’accéder à la copie au lieu d’accéder à la source de référence mène parfois à des
incohérences qui doivent être gérées.
 Atteindre un haut niveau d’efficience sur le plan de la gestion des espaces de stockage ou au
niveau du temps d’accès à la donnée restent deux critères majeurs de l’efficacité d’un cache.
Une telle efficacité dépend fortement de la complexité de sa mise en œuvre, cette complexité
est proportionnelle au besoin et au niveau des ressources.