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.
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
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)
Formule C
Ceiling(T/ (1+N)) = m
Pour l'optimisation des performances avec le fournisseur de cache dynamique, voir Optimisation du fournisseur de cache dynamique.
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
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
Formule E
Ct = Tt / Np