La taille du cache EJB (Enterprise JavaBeans) peut
avoir des conséquences sur les performances du serveur d'applications. Une des étapes d'optimisation de votre conteneur d'EJB
selon les niveaux de performance optimaux consiste à affiner le cache d'EJB.
Avant de commencer
Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL
en vue du traitement des incidents liés aux applications.
Pourquoi et quand exécuter cette tâche
La procédure ci-dessous décrit comment utiliser le service de trace de
diagnostic afin de déterminer au mieux la taille du cache.
Procédure
- Activez la trace du cache d'EJB. Pour savoir comment utiliser le service de trace, voir la rubrique
Utilisation de la trace.
![[IBM i]](../images/iseries.gif)
Pour plus d'informations sur les paramètres du
service de trace, voir la rubrique Paramètres du service de
trace des diagnostics.Configurez votre trace pour utiliser cette chaîne de trace :
com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy=all=enabled:com.ibm.ejs.util.cache.CacheElementEnumerator=
all=enabled
![[IBM i]](../images/iseries.gif)
Pour Taille maximale du fichier, attribuez une valeur au moins
égale à 200 Mo. Si vous
conservez la valeur par défaut (20 Mo), vous pouvez entrer
20 Mo de données dans le journal de trace et vous risquez de perdre des données en raison
du bouclage de la trace.
![[IBM i]](../images/iseries.gif)
Attribuez la valeur 5 à
Nombre maximal de fichiers historique. Cinq fichiers devraient suffire mais
si vous vous apercevez que les cinq fichiers sont saturés et qu'un bouclage de trace survient, augmentez
cette valeur.
![[IBM i]](../images/iseries.gif)
Arrêtez votre serveur, supprimez les journaux existants puis démarrez
votre serveur.
Arrêtez puis redémarrez votre serveur.
- Exécutez des scénarios standard pour capturer les données de trace de cache. Lorsque le scénario standard s'exécute alors que la trace est activée, les données
de trace de cache d'EJB doivent être analysées dans la procédure suivante.
- Affichez et analysez la sortie de trace.
- Ouvrez votre journal de trace. Recherchez une ou l'ensemble des chaînes suivantes :
![[IBM i]](../images/iseries.gif)
BackgroundLru 3 EJB Cache: Sweep (1,40) - Cache limit not reached : 489/2053
BackgroundLru > EJB Cache: Sweep (16,40) - Cache limit exceeded : 3997/2053 Entry
Trace: 2007/03/22 11:47:07.048 01 t=7A9690 c=UNK key=P8 (13007002)
ThreadId: 0000006a
FunctionName: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
Category: FINEST
ExtendedMessage: EJB Cache: Sweep (23,40) - Cache limit not reached : 0/2053
Trace: 2007/03/22 11:54:16.755 01 t=7BD3B0 c=UNK key=P8 (13007002)
ThreadId: 0000006d
FunctionName: EJB Cache: Sweep (75,37) - Cache limit exceeded : 3801/2053
SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
Category: FINER
ExtendedMessage: Entry
Dans les chaînes de trace qui incluent les mots Cache limit, un rapport
est disponible. par exemple 3997/2053.
Le premier chiffre correspond au nombre
de beans enterprise se trouvant actuellement dans le cache d'EJB (appelé la
capacité). Le deuxième chiffre correspond au paramètre de cache d'EJB (des
informations supplémentaires sont disponibles ultérieurement). Vous utilisez
ce rapport, particulièrement la capacité, dans vos analyses.
Recherchez également les instructions
Limite de cache non atteinte et
Limite
de cache atteinte.
- Limite de cache non atteinte
- La taille du cache est égale ou supérieure à la valeur appropriée. Si elle est
supérieure, vous perdez de la mémoire et vous devez ramener la taille du cache à une valeur
plus appropriée.
- Limite de cache dépassée
- Le nombre de beans actuellement utilisés est supérieur à la capacité
définie, ce qui indique que votre cache n'est pas correctement réglé.
La
capacité peut dépasser le paramètre de cache d'EJB car le paramètre n'est
pas une limite rigide. Le conteneur d'EJB n'arrête pas l'ajout de beans au
cache une fois la limite atteinte. Lorsque le cache est saturé, il ne sera
pas répondu à une demande de bean ou cette dernière sera différée jusqu'à ce que la taille
du cache soit inférieure à la limite. La limite de cache peut être dépassée mais
le conteneur d'EJB tente de nettoyer le cache et de le conserver inférieur à la taille
du cache d'EJB.
Lorsque la limite de cache est dépassée, une trace similaire à la
suivante peut s'afficher :
![[IBM i]](../images/iseries.gif)
BackgroundLru < EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053 Exit
EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053
Notez la chaîne
Evicted =. Si vous voyez cette chaîne, vous utilisez des beans
session avec état ou des beans entity configurés pour la mise en cache Option A ou B. S'il existe des objets supprimés, cela signifie que vous ne tirez pas le meilleur parti
de l'option de mise en cache choisie. La première étape consiste à essayer d'augmenter la taille
du cache d'EJB. Si une exécution continue de votre application
est à l'origine de suppressions supplémentaires, l'application
accède ou crée plus de beans entre les différents balayages de cache
d'EJB que le cache ne peut en contenir et ne réutilise
pas les beans existants.
Vous
pouvez envisager d'utiliser la mise en cache Option C pour vos beans entity ou
de vérifier votre application pour voir si elle ne supprime pas des beans session
avec état lorsqu'ils ne sont plus nécessaires.
Remarque : Les beans entity configurés
avec la mise en cache Option C se trouvent dans le cache uniquement lorsqu'ils se trouvent
dans une transaction et doivent être conservés dans le cache pendant l'intégralité
de la transaction.
C'est pourquoi, ils ne sont jamais supprimés lors d'un balayage
de cache mais ils sont retirés du cache à la fin de la transaction. De plus, si vous
utilisez uniquement des beans session sans état ou des beans entity avec la mise en
cache Option C (ou ces deux éléments), vous pouvez souhaiter augmenter l'intervalle de
nettoyage du cache d'EJB. L'intervalle de nettoyage peut être défini comme cela est
décrit dans la section relatives aux paramètres de cache EJB. Les beans session sans état ne se trouvent pas dans
le cache d'EJB et comme les beans entity utilisant la mise en cache Option C ne sont
jamais supprimés par la stratégie de mise en cache (LRU), il n'est pas nécessaire de
les balayer souvent. Lors de l'utilisation de beans session sans état ou de la mise en cache Option C, "Evicted = 0" doit apparaître dans l'exemple de trace présenté.
- Analysez votre journal de trace. Recherchez la chaîne de trace Cache
limit exceeded.
- Vous pouvez trouver plusieurs instances de cette chaîne. Examinez-les toutes
pour trouver la valeur de capacité la plus élevée de beans dans le cache d'EJB.
Redéfinissez
la taille du cache d'EJB et attribuez-lui une valeur correspondant à environ 110 % de ce chiffre. La définition de la taille du cache
d'EJB est décrite ultérieurement.
- Vous pouvez ne trouver aucune instance de cette chaîne. Vous n'avez alors
pas dépassé la capacité du cache d'EJB (ce qui est votre objectif final). Cela peut
également signifier que la taille du cache est trop importante et que vous utilisez
de la mémoire qui n'est pas nécessaire. Dans ce cas, il est nécessaire d'optimiser le
cache en réduisant la taille du cache sans dépasser la limite puis
en l'augmentant à la valeur optimale. La définition de la taille du cache
d'EJB est décrite ultérieurement.
Votre objectif final consiste à définir la limite de cache à une valeur qui permet
de ne pas gaspiller de ressources tout en étant assez importante pour ne pas être dépassée. Une
configuration correcte génère une trace avec comme seul message
Cache limit not reached et un rapport
où le chiffre correspondant à la capacité peut être proche, mais inférieur, à 100 % du paramètre
de cache d'EJB.
Remarque : Il est recommandé de ne pas attribuer à la taille de cache une
valeur inférieure à la valeur par défaut, 2053.
- Modifiez les paramètres de cache en fonction de votre analyse. Voir la rubrique relative aux paramètres de cache EJB pour plus
d'informations sur l'exécution de cette opération.
![[IBM i]](../images/iseries.gif)
Arrêtez votre serveur, supprimez tous les journaux puis redémarrez le serveur.
Arrêtez puis redémarrez votre serveur.
- Répétez la procédure précédente jusqu'à ce que les paramètres vous
semblent corrects.
- Désactivez la trace du cache d'EJB. Lorsque le cache est correctement réglé, vous pouvez retirer la trace, retirer
les anciens journaux puis redémarrer votre serveur.
Que faire ensuite
A partir de votre analyse, il est possible de définir le cache EJB de manière
optimale selon le conteneur d'EJB, mais peut-être pas selon la perspective WebSphere Application
Server. Une taille de cache
plus importante offre plus d'impacts et de meilleures performances de cache d'EJB mais utilise
plus de mémoire. La mémoire utilisée par le cache n'est pas disponible pour d'autres zones du produit, ce qui
peut avoir des conséquences sur les performances générales. Dans un système disposant d'une mémoire
importante, cela peut ne pas être un problème. Un réglage correct du cache d'EJB peut augmenter les
performances générales. Toutefois, vous devez prendre en compte les performances du système par rapport aux performances
du cache d'EJB lors de la configuration du cache.