Performance des caches avec Ehcache & Terracotta

Introduction aux caches distribués ... avec Terracotta

 

Ehcache_terracottaLe principe d'un cache logiciel est de permettre à une application d'éviter de répéter des appels de méthodes coûteuses (temps d’exécution ou nombre d'appels).

Le cache se déclenche  en stockant les résultats dès les 1er appels, directement en cache mémoire pour une meilleure accession à ces valeurs lors des appels suivants (exemple : un appel en base de données)

Terracotta est un middleware Java de type NAM (Network Attached Memory) répondant entièrement à cette problématique.

Un NAM permet à plusieurs instances de serveurs mis en cluster, d'accéder aux mêmes graphes d'objets au sein d'une mémoire virtuelle partagée.

Terracotta reste ni plus ni moins qu'un système de cache (EhCache) déployé dans un environnement distribué.

Intérêts du cache :

  • Réduire la consommation des ressources applicatives (et donc indirectement les ressources systèmes)
  • Réduire l’activité de la base de données et de son trafic réseau
  • Améliorer la rapidité d’accession à l’information cliente (accès RAM vs accès disque BDD)
  • Faciliter la scalabilité des données en distribuant les données dans un environnement clusterisé.
  • Faire des économies de licence, notamment de bases de données

 

Difficulté à bien identifier les données "cachables"

L'efficacité d'un cache, qu'il soit répliqué ou distribué, se mesure en ratio : le rapport entre les requêtes qui sollicitent le cache et la totalité des requêtes. Un OffLoad important confirmera de l'efficacité d'un cache en place.

On peut comparer ce  principe avec la loi de pareto, qui tendra à performer votre système si celui ci met en cache de manière intelligente les données les plus demandées et pas la totalité. (également la loi d'Amdhal)

Toute la difficulté de mise en place d'une telle architecture repose en grande partie sur cette phase amont : identifier les données cachables, les isoler, estimer leurs volumétries (nombre et taille) et appliquer une politique de cycle de vie de ces données à l'intérieur du cache.

Simplicité de mise en place :

  • Plus besoin de répliquer préventivement les données : elles sont sécurisées au sein du NAM, et seront transmises, à la demande et de manière optimisée, aux seules applications devant y accéder.

 

Cache répliqué :

fonctionnement en mode « serveur » de données. Chacune des instances a son propre référentiel de cache en local.

lors de la modification d’un objet, les autres instances peuvent invalider l’objet en cache, ou bien en recevoir la copie.

la réplication peut être synchrone ou asynchrone

certains caches peuvent supporter la persistance, conserver et reprendre des données sur disque

une nouvelle instance de ce type de cache peut à tout moment initialiser son cache auprès du cluster d’instances actives : synchronisation à la volée

 

Cache distribué :

Les objets peuvent être répartis (ie. distribués) sur un nombre variable d’instances de serveurs : chaque instance sera responsable d’un certain nombre de données.

Les données ne sont ni persistantes, ni répliquées entre les différentes instances. C'est à dire que si une des instances tombent, les données qui étaient hébergées par cette instance sont perdues et le code applicatif devra à nouveau solliciter la source (la base de données par exemple…) pour récupérer les dernières valeurs.

 

Architecture Terracotta :

Dans cette architecture incluant un serveur de cache "centralisé" , toute modification apportée à un graphe de sous ensemble d'objets communs à l'applicatif, est immédiatement répliquée sur le NAM.

Présentation_terracotta

 

Principaux éléments composant TERRACOTTA:

  • Un/des serveur(s) indépendant(s) chargé(s) de la gestion de la mémoire partagée. Afin de garantir une reprise sur incident immédiate, toutes les données sont sécurisées de manière asynchrone dans une base de données interne, et le serveur lui-même peut être mis en redondance active ou passive.
  • Un « bootClassLoader » spécial qui instrumente la JVM des applications clientes et assure la liaison avec le serveur Terracotta. Un fichier de configuration « tc-config.xml » permet alors de définir quels graphes d'objets doivent être déployés sur le NAM (il est également possible d'utiliser des annotations).
  • Des modules d'intégration Terracotta Integration Module, qui fournissent les interfaces nécessaires pour s'intégrer aux principaux frameworks d'entreprise : Spring, Hibernate, EhCache, Struts...
  • Le module BigMemory ...

logo-bigmemory

Le module BigMemory permet de stocker une grande quantité de données dans la mémoire du processus Java mais en dehors de l'espace mémoire de la heap grâce à l'utilisation les DirectByteBuffer qui impacteront donc directement la mémoire native de la machine.

L'objectif de BigMemory, est de limiter la taille de la heap pour éviter la surconsommation du GarbageCollector tout en supportant un cache en mémoire vive à grande capacité (jusqu’à 350Go théorique !). Le principal défaut de cette solution : la synchronisation des objets Java dans le cache par le mécanisme de sérialisation.

Les simples valeurs de overFlowToHeap et maxMemoryOffHeap suffisent à la configuration de BigMemory en complément de EhCache.

 

Alors quel type de Cache choisir : Heap, OffHeap, FileStore ?

Les choix sur le type de stockage à adopter résident essentiellement sur la volumétrie de données attendue dans le cache, comme le montre le schéma  ci-dessous :

tiered_storage

réf : http://ehcache.org/documentation/configuration/bigmemory

Preview du prochain article :

Après cet aperçu d'une architecture de cache combinant EhCache / Terracotta Server (scale out), ou EhCache / Big Memory (scale up), nous allons passer à la mise en pratique en testant l'impact performance d'une mise en cache répliqué sur un applicatif existant.

Pour cela, la suite de la démonstration aura pour but de :

vous montrer la facilité d'intégrer EhCache et un Terracotta Server dans notre application Petclinic optimisée, tournant actuellement en cluster sous Glassfish

Mesurer la performance globale de cette architecture, grâce à des tirs de charges : impact débit tx, activité base de données ...

 

Laisser un commentaire

Merci d'effectuer cette opération simple pour valider le commentaire *

Mots-clés
RSS Feed