Planification de la capacité de la mémoire cache dynamique

L'API de cache dynamique est disponible pour les applications Java EE qui sont déployées dans WebSphere Application Server. Ce cache dynamique permet de mettre en cache les données métier et les fichiers HTML générés ou de synchroniser les données en cache de la cellule à l'aide du service DRS de réplication des données.

Présentation

Toutes les instances du cache dynamique créées avec le fournisseur de cache dynamique de WebSphere eXtreme Scale sont par défaut à disponibilité élevée. Le niveau et le coût de la mémoire de la haute disponibilité dépendent de la topologie utilisée.

Si vous utilisez une topologie imbriquée, la taille du cache est limitée à la quantité de mémoire disponible dans un processus serveur unique et chaque processus serveur stocke une copie complète du cache. Tant que l'exécution de ce processus serveur unique se poursuit, le cache survit. Les données de cette mémoire sont perdues uniquement en cas d'arrêt de tous les serveurs qui y accèdent.

Dans le cas d'une topologie partitionnée imbriquée, la taille du cache est limitée à l'ensemble de l'espace disponible dans tous les processus serveur. Le fournisseur de cache dynamique eXtreme Scale par défaut utilise une réplique pour chaque fragment primaire, de sorte que chaque donnée mise en cache est stockée deux fois.

Utilisez la formule A pour déterminer la capacité du cache partitionné imbriqué.

Formule A

D * C / (1 + S) = M

Où :
  • D = Mémoire disponible par processus conteneur
  • C = nombre de conteneurs
  • S = nombre de fragments réplique
  • M = taille totale du cache

Pour une grille de données WebSphere Application Server Network Deployment disposant d'un espace disponible de 256 Mo dans chaque processus, avec 4 processus serveur, une instance du cache sur tous ces serveurs peut stocker jusqu'à 512 mégaoctets de données. Dans ce mode, le cache peut survivre à une panne de serveur sans perte de données. De la même manière, deux serveurs au maximum peuvent être arrêtés séquentiellement sans perte de données. Pour l'exemple suivant, la formule est la suivante :

256 Mo * 4 conteneurs/ (1 primaire + 1 réplique) = 512 Mo.

Les caractéristiques de taille des mémoires cache utilisant une topologie distante sont similaires à celles qui utilisent une topologie partitionnée imbriquée, mais les premières sont limitées à la quantité d'espace disponible dans tous les processus conteneur eXtreme Scale.

Dans une topologie distante, il est possible d'augmenter le nombre de fragments réplique pour atteindre un niveau de disponibilité plus élevé, au prix d'une augmentation de la quantité de mémoire. Dans la plupart des applications de cache dynamique, cela est inutile, mais vous pouvez modifier le fichier dynacache-remote-deployment.xml pour augmenter le nombre de répliques.

Utilisez les formules suivantes, B et C, afin de déterminer l'impact de l'ajout de fragments de réplique sur la haute disponibilité du cache.

Formule B

N = Minimum(T -1, S)

Où :
  • N = nombre d'échecs simultanés de processus
  • T = nombre total de conteneurs
  • S = nombre total de fragments réplique

Formule C

Ceiling(T/ (1+N)) = m

Où :
  • T = nombre total de conteneurs
  • N = nombre total de fragments réplique
  • m = nombre minimal de conteneurs nécessaires pour prendre en charge les données en cache.

Pour l'optimisation des performances avec le fournisseur de cache dynamique, voir Optimisation du fournisseur de cache dynamique.

Définition de la taille du cache

Pour qu'une application utilisant le fournisseur de cache dynamique WebSphere eXtreme Scale puisse être déployée, les principes généraux décrits dans la section précédente doivent être combinés avec les données environnementales des systèmes de production. Les premiers chiffres à identifier sont le nombre total de processus conteneur et la quantité de mémoire disponible dans chaque processus pouvant contenir les données du cache. Dans une topologie imbriquée, les conteneurs du cache sont aussi localisés dans les processus serveur WebSphere Application, de sorte qu'il existe un conteneur par serveur partageant le cache. Le meilleur moyen de définir l'espace disponible dans le processus est d'identifier la quantité de mémoire supplémentaire de l'application sans activer la mise en cache et WebSphere Application Server. Pour cela, vous pouvez analyser les données détaillées de récupération de place. Lorsque la topologie utilisée est distante, vous trouvez ces informations dans la sortie détaillée de la récupération de place d'un conteneur autonome ayant démarré récemment et dans lequel aucune donnée de cache n'a encore été entrée. Dernier élément auquel vous devez penser : vous devez réserver des segments de la mémoire pour la récupération de place. La somme de l'espace restant dans le conteneur WebSphere Application Server ou dans le conteneur autonome et de la taille réservée pour le cache ne doit pas dépasser 70 % du total des segments de mémoire.

Une fois ces informations collectées, les valeurs peuvent être entrées dans la formule A décrite précédemment, pour déterminer la taille maximale du cache partitionné. Une fois cette taille connue, l'étape suivante consiste à déterminer le nombre total d'entrées du cache pouvant être prises en charge, ce qui suppose d'identifier la taille moyenne de chaque entrée. Il suffit pour cela d'ajouter 10% à la taille de l'objet client. Voir le guide sur l'optimisation du cache dynamique et du service de réplication des données pour plus d'informations sur l'utilisation du cache dynamique.

Lorsque la compression est activée, elle affecte la taille de l'objet client et non l'espace restant dans le système de mise en cache. Utilisez la formule suivante pour déterminer la taille d'un objet mis en cache lorsque la compression est utilisée :

T = O * C + O * 0.10

Où :
  • T = Taille moyenne de l'objet mis en cache
  • O = Taille moyenne de l'objet client non compressé
  • C = Rapport de compression exprimé sous la forme d'une fraction.
Un rapport de compression de 2 à 1 est égal à 1/2 = 0.50. Une valeur moins élevée est recommandée. Si l'objet stocké est un objet Java simple normal principalement rempli de types primitifs, vous pouvez supposer que le rapport de compression est de l'ordre de 0,60 à 0,70. Si l'objet mis en cache est un objet servlet, JSP ou WebServices, la meilleure méthode pour déterminer le rapport de compression consiste à compresser un exemple représentatif avec un utilitaire de compression ZIP. Si cette opération est impossible, considérez qu'un rapport de compression compris entre 0,2 et 0,35 est fréquent pour ce type de données.

Ensuite, utilisez ces informations pour déterminer le nombre total d'entrées du cache qui peuvent être prises en charge. Utilisez la formule D suivante :

Formule D

T = S / M

Où :
  • T = Nombre total d'entrées du cache
  • S = Taille totale disponible pour les données du cache, calculée à l'aide de la formule A
  • M = Taille moyenne de chaque entrée du cache
Enfin, vous devez définir la taille de l'instance de cache dynamique pour appliquer cette limite. A cet égard, le fournisseur de cache dynamique WebSphere eXtreme Scale est différent du fournisseur de cache dynamique par défaut. Utilisez la formule suivante pour déterminer la valeur de la taille de l'instance de cache dynamique. Cette formule est la suivante :

Formule E

Ct = Tt / Np

Où :
  • Tt = Taille cible totale du cache
  • Ct = Paramètre de la taille du cache à définir dans l'instance de cache dynamique
  • Np = Nombre de partitions. La valeur par défaut est 47.
Associez la taille de l'instance de cache dynamique à une valeur calculée par la formule E pour chaque serveur partageant l'instance du cache.