Optimisation du cache EJB avec le service de trace

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

  1. Activez la trace du cache d'EJB. Pour savoir comment utiliser le service de trace, voir la rubrique Utilisation de la trace. [IBM i][AIX Solaris HP-UX Linux Windows]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][AIX Solaris HP-UX Linux Windows]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][AIX Solaris HP-UX Linux Windows]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.

  2. [IBM i][AIX Solaris HP-UX Linux Windows]Arrêtez votre serveur, supprimez les journaux existants puis démarrez votre serveur.
  3. [z/OS]Arrêtez puis redémarrez votre serveur.
  4. 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.
  5. Affichez et analysez la sortie de trace.
    1. Ouvrez votre journal de trace. Recherchez une ou l'ensemble des chaînes suivantes :

      [IBM i][AIX Solaris HP-UX Linux Windows]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

      [z/OS] 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][AIX Solaris HP-UX Linux Windows]BackgroundLru <  EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053 Exit

      [z/OS] 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é.
    2. 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.
  6. 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.
  7. [IBM i][AIX Solaris HP-UX Linux Windows]Arrêtez votre serveur, supprimez tous les journaux puis redémarrez le serveur.
  8. [z/OS]Arrêtez puis redémarrez votre serveur.
  9. Répétez la procédure précédente jusqu'à ce que les paramètres vous semblent corrects.
  10. 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.


Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tejb_tunecash
Nom du fichier : tejb_tunecash.html