Optimisation du conteneur d'EJB

Si vous utilisez des applications qui affectent la taille du cache du conteneur d'Enterprise JavaBeans (EJB), il est possible que les performances de vos applications soient affectées par un paramètre de taille incorrect. Cette rubrique présente la persistance gérée par le conteneur (CMP), bien que les beans entity ne sont pas pris en charge dans un module EJB 3.x.

Taille du cache EJB

Contrôlez Tivoli Performance Viewer pour vérifier si le paramètre de la taille de mémoire cache du conteneur d'EJB est correctement optimisé pour votre application.

Si l'application a saturé la mémoire cache, donnant ainsi lieu à des suppressions, Tivoli Performance Viewer affiche un nombre élevé d'appels de la méthode ejbStores et probablement une utilisation du processeur inférieure à celle prévue sur la machine de poste de travail.

Ce paramètre doit être ajusté pour toutes les applications qui utilisent des beans enterprise, si la formule ci-après génère un résultat supérieur à 2000.
Taille_Cache_EJB = (Nombre le plus élevé de beans entity de l'option B ou C associés à une 
transaction * nombre maximal de transactions simultanées) + 
(Nombre le plus élevé de beans entity uniques de l'option A auxquels l'application est censée accéder lors d'une 
charge de travail d'application type) + 
(Nombre de beans session avec état actifs lors d'une charge de travail type) + 
(Nombre de types de bean session sans état utilisés lors d'une charge de travail type)

Où :
Les beans entity des options B et C ne sont conservés dans le cache des EJB que pendant la durée de vie 
de la transaction à laquelle ils sont associés. Par conséquent, le premier terme de la formule 
calcule les besoins moyens en mémoire cache d'EJB de ces types de bean.

Les beans entity de l'option A sont conservés indéfiniment dans la mémoire cache des
EJB et ne sont supprimés
 de cette dernière que lorsque le nombre de beans en mémoire cache
commence à être supérieur au nombre défini par 
la taille de la mémoire cache. Si votre application utilise des beans en lecture seule, envisagez d'en faire des beans Option A pour le calcul d'optimisation. 

Les beans session avec état sont conservés dans le cache des EJB jusqu'à ce
qu'ils soient supprimés par 
l'application ou que le délai d'expiration de leur session est atteint.

Une seule instance de bean session sans état est conservée pour chaque type d'EJB dans le 
cache pendant la durée d'exécution des méthodes sur ce bean session sans 
état. Si plusieurs méthodes sont implémentées simultanément sur le même 
type de bean session sans état, chaque méthode est exécutée sur sa propre instance de bean, mais 
un seul emplacement de mémoire cache est utilisé pour toutes ces instances. 

Cette formule Calcule la limite supérieure du nombre maximal de beans enterprise pouvant être actifs simultanément sur le serveur d'applications. La mémoire cache du conteneur d'EJB étant conçue pour contenir tous ces beans afin d'optimiser les performances, de meilleures performances peuvent être obtenues en choisissant une taille de cache supérieure au résultat obtenu à l'aide de la formule ci-dessus.

Vous pouvez définir la taille du cache EJB dans la console d'administration sous Serveurs > Types de serveurs > Serveurs d'applications WebSphere > nom_serveur > Paramètres de conteneur EJB > Paramètres de cache EJB.

En outre, lors de l'ajustement de la taille du cache EJB, vous pouvez optimiser le paramètre de l'unité d'exécution de la gestion du conteneur d'EJB pour répondre aux besoins de l'application. L'unité de gestion est contrôlée par l'intermédiaire du paramètre Intervalle entre les nettoyages. Ce paramètre contrôle la fréquence à laquelle l'unité d'exécution d'un démon du produit tente de supprimer des instances de bean de la mémoire cache qui n'ont pas été utilisées récemment, pour essayer de limiter le nombre d'instances de bean en dessous de la taille de la mémoire cache. Ce comportement garantit que le conteneur d'EJB place et recherche rapidement les éléments dans la mémoire cache. Conservez la valeur par défaut de l'intervalle. Cependant, dans certains cas, il peut s'avérer intéressant de vérifier si le fait de réduire cette valeur n'est pas plus avantageux.

Pour plus d'informations sur une optimisation de la mémoire cache EJB à l'aide du service de trace de la mémoire cache EJB, voir les rubriques relatives à l'optimisation de la mémoire cache EJB et à l'utilisation du service de trace.

Optimisation des beans session avec état EJB

Les beans session avec état sont configurés de différentes manières, avec des portées diverses, en fonction de la version de WebSphere Application Server.

WebSphere Application Server version 6.1 et antérieure prend en charge la configuration d'un délai d'attente de bean session avec état, par bean, à l'aide du fichier ibm-ejb-jar-ext.xmi.

WebSphere Application Server version 7.0 prend en charge la configuration d'un délai d'attente de bean session avec état, par bean, à l'aide du fichier ibm-ejb-jar-ext.xmi (pour les modules EJB 2.x) et du fichier ibm-ejb-jar-ext.xml (pour les modules EJB 3.x).

WebSphere Application Server version 8.x prend en charge la configuration d'un délai d'attente de bean session avec état, par bean, à l'aide du fichier ibm-ejb-jar-ext.xmi (pour les modules EJB 2.x), du fichier ibm-ejb-jar-ext.xml (pour les modules EJB 3.x), de l'élément XML stateful-timeout et de l'annotation @StatefulTimeout. En outre, vous pouvez configurer une valeur de délai d'attente de session avec état (global) côté serveur à l'aide de la propriété système com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout.

Configurations prises en charge Configurations prises en charge: Pour les fichiers de liaison et d'extension IBM®, l'extension de nom de fichier .xmi ou .xml est différente selon que vous utilisiez un module ou une application antérieure à Java EE 5 ou un module ou une application ultérieure à Java™ EE 5. Un fichier de liaison ou d'extension IBM porte le nom ibm-*-ext.xmi ou ibm-*-bnd.xmi où * correspond au fichier d'extension ou de liaison, tel app, application, ejb-jar ou web. Les conditions suivantes s'appliquent :
  • Pour une application ou un module qui utilise une version Java EE antérieure à la version 5, l'extension de fichier doit être .xmi.
  • Pour une application ou un module qui utilise Java EE 5 ou version ultérieure, l'extension de fichier doit être .xml. Si des fichiers .xmi sont inclus dans l'application ou le module, le produit les ignore.

Toutefois, un module Java EE 5 ou version ultérieure peut exister dans une application qui inclut des fichiers antérieurs à Java EE 5 et utilise l'extension de nom de fichier .xmi.

Les fichiers ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi et ibm-portlet-ext.xmi continuent d'utiliser les extensions de fichier .xmi.

sptcfg

Les beans session sans état n'ont pas de délai d'attente car ils n'ont pas d'état conversationnel et ne sont pas dédiés à un client spécifique.

Vous pouvez utiliser Rational Application Developer pour mettre à jour le fichier ibm-ejb-jar-ext.xmi, qui est utilisé pour configurer la valeur de délai d'attente de session avec état pour les beans d'un module EJB 2.x. Pour plus d'informations, reportez-vous à la rubrique relative à la définition des paramètres de délai d'attente de session pour un bean dans le centre de documentation de Rational Application Developer.

Par exemple, le code XMI généré permettant de définir une valeur de délai d'attente de session avec état de 15 minutes est le suivant :
<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension_1"
  timeout="15">

Vous pouvez modifier le fichier ibm-ejb-jar-ext.xml pour définir un délai d'attente de session avec état pour les beans d'un module EJB 3.x. Par exemple, le code permettant de définir une valeur de délai d'attente de session avec état de 15 minutes pour le bean myBean est le suivant :

<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension"
  timeout="15">
    <enterpriseBean xmi:type="ejb:Session" href="META-INF/ejb-jar.xml#MyBean"/>
 </ejbExtensions>

Vous pouvez configurer un délai d'attente de bean session avec état à l'aide de l'annotation @StatefulTimeout. L'annotation @StatefulTimeout prend un paramètre de valeur obligatoire qui représente la durée du délai d'attente, et un paramètre d'unité facultatif. Si le paramètre d'unité facultatif n'est pas indiqué, les minutes sont utilisées par défaut. L'annotation @StatefulTimeout est introduite avec EJB 3.1.

Par exemple, utilisez l'annotation @StatefulTimeout pour déclarer une valeur de délai d'attente de 100 secondes :

@StatefulTimeout(value=100 unit=java.util.concurrent.TimeUnit.SECONDS)

Vous pouvez configurer un délai d'attente de bean session avec état à l'aide de l'élément XML stateful-timeout du descripteur de déploiement ejb-jar.xml. L'élément stateful-timeout est introduit avec EJB 3.1.

Par exemple, pour définir une valeur de délai d'attente de 100 secondes :

<stateful-timeout>
     <timeout>100</timeout>
     <unit>Seconds</unit>
</stateful-timeout>

L'annotation @StatefulTimeout et l'élément XML stateful-timeout sont les mécanismes définis par une spécification qui permettent de déclarer des valeurs de délai d'attente par bean, à partir de EJB 3.1. Avant EJB 3.1, il n'existe aucun mécanisme défini par une spécification permettant de déclarer un délai d'attente de session avec état par bean. Lorsque l'élément XML stateful-timeout ou l'annotation @StatefulTimeout est utilisé, une valeur égale à -1 signifie que le bean n'arrive jamais à expiration et une valeur égale à 0 signifie que le bean est immédiatement admissible pour suppression.

Vous pouvez configurer un délai d'attente de bean session avec état de façon globale (côté serveur) à l'aide de la propriété système com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout. La propriété système com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout est exprimée en minutes. La valeur spécifiée doit être supérieure ou égale à 0 et si une valeur non valide est spécifiée, la valeur par défaut de 10 minutes est utilisée à la place. La valeur de délai d'attente globale ne peut pas être configurée à l'aide de l'élément XML ou d'annotations. La valeur de délai d'attente globale s'applique à tous les beans session avec état qui s'exécutent dans le serveur, y compris les beans sessions avec état des modules EJB 2.x ou EJB 3.x.

Dans WebSphere Application Server version 8.x, les paramètres de délai d'attente avec état de niveau bean sont prioritaires sur le paramètre de délai d'attente côté serveur. Le paramètre de délai d'attente côté serveur est prioritaire sur le délai d'attente (non spécifié) par défaut. L'ordre de priorité suivant permet de déterminer la valeur de délai d'attente de session avec état d'un bean qui s'exécute dans WebSphere Application Server Version 8.x :
  1. Elément XML stateful-timeout
  2. Annotation @StatefulTimeout
  3. ibm-ejb-jar-ext.xml ou ibm-ejb-jar-ext.xmi
  4. Propriété système com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout
  5. Si aucune valeur de délai d'attente côté bean ou côté serveur n'est spécifiée de façon explicite, la valeur de délai d'attente par défaut de 10 minutes est appliquée.

Dcom.ibm.websphere.ejbcontainer.poolSize

Si l'application utilise la majorité des instances de bean du pool, Tivoli Performance Viewer l'indique. Si la majorité des instances de bean est utilisée, augmentez la taille des pools de beans qui arrivent à saturation en ajoutant ce paramètre dans la balise des propriétés personnalisées de la machine virtuelle Java. Par exemple :

-Dcom.ibm.websphere.ejbcontainer.poolSize=<nom_application>#<nom_module>#
<enterprisebean_name>=<minSize>,<maxSize>

Où :

<application_name> est le nom de l'application Java EE tel qu'il est défini dans le descripteur de déploiement du fichier d'archive d'entreprise (EAR) pour le bean dont la taille de pool est en cours de définition.

<module_name> est le nom du fichier d'archive Java (JAR) du module EJB pour le bean dont la taille de pool est en cours de définition.

<bean_name> est le nom du bean enterprise Java EE tel qu'il est défini dans le descripteur de déploiement du module EJB pour le bean dont la taille de pool est en cours de définition.

<minSize> est le nombre d'instances de bean que le conteneur conserve dans le pool, indépendamment de la durée depuis laquelle les beans sont dans le pool (les beans supérieurs à ce nombre sont effacés du pool au fil du temps afin d'optimiser l'utilisation de la mémoire)

<taille_maxi> est le nombre d'instances de bean dans le pool au-delà duquel plus aucune instance de bean n'est placée dans le pool une fois qu'elles sont utilisées (autrement dit, dès que le pool atteint cette taille, les beans supplémentaires sont effacés plutôt qu'ajoutés au pool, ce qui limite le nombre de beans dans le pool, afin que l'utilisation de la mémoire n'augmente pas de façon illimitée).

Pour que le nombre d'instances dans le pool soit fixe, les éléments minSize et maxSize peuvent avoir la même valeur. Un pool d'instances distinct pour chaque type EJB qui s'exécute dans le serveur d'applications existe et chaque pool démarre sans instance ; le nombre d'instances augmente à mesure que les beans sont utilisés et placés dans le pool.

Lorsqu'une instance de bean est requise par le conteneur et qu'aucun bean n'est disponible dans le pool, le conteneur crée une instance de bean, l'utilise, puis la place dans le pool, sauf si le nombre d'instances dans le pool est déjà égal à la valeur du paramètre maxSize. Par exemple, l'instruction
Dcom.ibm.websphere.ejbcontainer.poolSize=ivtApp#ivtEJB.jar#ivtEJBObject=125,1327  
définit une taille minimale de 125 et une taille maximale de 1327 sur le bean ivtEJBObject dans le fichier ivtEJB.jar, dans l'application ivtApp.

L'application, ivtApp, est remplacée par le nom réel de l'application, le fichier ivtEJB.jar est remplacé par le fichier JAR contenant le bean dont la taille de pool doit être augmentée, et ivtEJBObject correspond au nom du bean enterprise dont la taille de pool doit être augmentée. Le nombre minimal de beans dans ce pool est 125. Le nombre maximal de beans dans ce pool est 1327. Définissez ces valeurs de sorte qu'aucun bean ne soit supprimé du pool. Dans la plupart des cas, indiquez des valeurs identiques si la quantité de mémoire est suffisante car, dans ce cas là, la taille du pool reste fixe.

Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation

Vous devez comprendre comment votre application gère la création d'objets de clé principale à utiliser par les beans CMP et BMP (persistance gérée par bean) dans le produit.

Le conteneur d'EJB utilise la clé principale d'un bean entity comme identificateur dans des structures de données internes pour optimiser les performances. Toutefois, le conteneur d'EJB doit copier ces objets de clé principale lors du premier accès au bean pour s'assurer que les objets stockés dans les mémoires cache internes sont séparés de ceux utilisés dans une application. Ce processus s'exécute au cas où l'application modifie la clé principale ou en change, pour que les structures internes restent cohérentes. Si l'application ne modifie aucune des clés principales permettant de créer des beans entity et d'y accéder une fois qu'ils sont créés, un indicateur spécial peut être utilisé pour s'assurer que le conteneur d'EJB ignore la copie de l'objet de clé principale et économiser ainsi des cycles de processeur et améliorer les performances. Ce mécanisme peut être activé à vos risques et périls en ajoutant la propriété –D ci-après à la zone des propriétés personnalisées de la machine JVM.
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true
Configurations prises en charge Configurations prises en charge: Les beans entity ne sont pas pris en charge dans les modules EJB 3.x et les versions suivantes.sptcfg

L'avantage de cette optimisation en termes de performances dépend de l'application. Si l'application utilise des types primitifs pour les clés principales des beans enterprise, les performances ne seront pas améliorées car ces objets sont déjà inaltérables et le mécanisme de copie prend déjà ce facteur en compte. Si toutefois l'application utilise de nombreuses clés principales complexes, c'est à dire un objet pour une clé principale ou plusieurs zones, ce paramètre peut améliorer considérablement les performances.

Dcom.ibm.ws.pm.deferredcreate

Le gestionnaire de persistance permet au conteneur d'EJB de conserver les données des beans entity CMP dans la base de données.

Lorsque vous créez des beans entity en appelant la méthode ejbCreate, par défaut, le gestionnaire de persistance insère immédiatement la ligne vide avec uniquement la clé principale dans la base de données. Dans la plupart des cas, après avoir créé le bean, vous devez modifier les zones du bean créé ou des autres beans à l'intérieur de la même transaction. Si vous souhaitez reporter l'insertion dans la base de données jusqu'à la fin de la transaction, pour éliminer un accès à la base de données, vous pouvez définir cet indicateur –D dans la zone des propriétés personnalisées de la machine JVM. Les données seront insérées dans la base de données et la cohérence sera assurée.
Configurations prises en charge Configurations prises en charge: Les beans entity ne sont pas pris en charge dans les modules EJB 3.x et les versions suivantes.sptcfg
-Dcom.ibm.ws.pm.deferredcreate=true

L'avantage de cette optimisation en termes de performances dépend de l'application. Si les transactions des applications EJB effectuent de nombreuses insertions, cette optimisation peut s'avérer intéressante pour les applications. Si les applications effectuent peu d'insertions, les avantages de cette optimisation sont moins importants.

Dcom.ibm.ws.pm.batch

Lorsqu'une application EJB accède à plusieurs beans CMP à l'intérieur d'une même transaction, suivant les opérations effectuées sur les beans (mises à jour, insertions, lectures) le nombre d'opérations effectuées sur la base de données correspond directement au nombre d'opérations effectuées sur les beans CMP. Si le système de base de données que vous utilisez prend en charge l'envoi par lots des instructions de mise à jour, vous pouvez activer cet indicateur et améliorer ainsi les performances sur toutes les interactions avec la base de données qui impliquent plusieurs mises à jour dans une même transaction.

Configurations prises en charge Configurations prises en charge: Les beans d'entité ne sont pas pris en charge dans les modules EJB 3.x et les versions suivantes.sptcfg
Utilisez cet indicateur, lequel prend en charge le gestionnaire de persistance, pour ajouter toutes les instructions de mise à jour dans une même instruction d'insertion par lots envoyée à la base de données. Ce processus permet de limiter le nombre d'aller-retours avec la base de données et d'améliorer ainsi les performances. Si vous savez que votre application a la particularité de mettre à jour plusieurs beans CMP dans une même transaction et que la base de données prend en charge les mises à jour par lots, vous pouvez définir l'indicateur –D dans la zone des propriétés personnalisées de la machine JVM. Par exemple :
-Dcom.ibm.ws.pm.batch=true

L'avantage de cette optimisation en termes de performances dépend de l'application. Si l'application met rarement ou jamais à jour les beans CMP ou qu'elle ne met à jour qu'un bean par transaction, les performances ne seront pas améliorées. Si l'application met à jour plusieurs beans par transaction, ce paramètre permet d'améliorer les performances de vos applications.

Le tableau suivant établit la liste des bases de données en arrière plan qui acceptent la mise à jour par lots.
Tableau 1. Bases de données d'arrière plan prenant en charge la mise à jour par lots. Le tableau suivant établit la liste des bases de données en arrière plan qui acceptent la mise à jour par lots.
Base de données Prend en charge la mise à jour par lots Prend en charge la mise à jour par lots avec contrôle d'accès simultané optimiste (OCC)
DB2 yes non
Oracle yes non
DB2 Universal Driver yes yes
Informix yes yes
SQLServer yes yes
Apache Derby yes yes
Configurations prises en charge Configurations prises en charge: La mise à jour par lots avec OCC ne peut pas être réalisée sur des bases de données qui ne la prennent pas en charge, même si elle est spécifiée par la tentative d'accès.sptcfg

com.ibm.ws.pm.useLegacyCache

Spécifie le nom de la classe Java que le produit utilise pour mettre en oeuvre l'interface javax.rmi.CORBA.UtilDelegate.

Configurations prises en charge Configurations prises en charge: Les beans d'entité ne sont pas pris en charge dans les modules EJB 3.x et les versions suivantes.sptcfg
Le gestionnaire de persistance dispose de deux types de mécanismes de mise en mémoire cache : mémoire cache héritée et mémoire cache à deux niveaux. Généralement, la mémoire cache à deux niveaux est plus efficace que la mémoire cache héritée en raison des optimisations de ce mode. Par défaut la mémoire cache est héritée, bien que celle à deux niveaux soit recommandée. Définissez cette configuration par la propriété système comme suit :
com.ibm.ws.pm.useLegacyCache=false

com.ibm.ws.pm.grouppartialupdate and com.ibm.ws.pm.batch

La fonction de mises à jour partielles améliore les performances des applications avec beans enterprise dans certains scénarios. Le gestionnaire de persistance dispose de deux types de mécanismes de mise en mémoire cache, mémoire cache héritée et mémoire cache à deux niveaux. Normalement la mémoire cache à deux niveaux a un meilleur comportement que la mémoire cache héritée en raison des optimisations de ce mode.

Configurations prises en charge Configurations prises en charge: Les beans d'entité ne sont pas pris en charge dans les modules EJB 3.x et les versions suivantes.sptcfg
Dans certaines applications pour lesquelles vous devez effectuer des mises à jour par lots et des mises à jour partielles, vous devez configurer les propriétés système suivantes afin de profiter de toutes les mises à jour :
'com.ibm.ws.pm.grouppartialupdate=true' and 'com.ibm.ws.pm.batch=true'

Icône indiquant le type de rubrique Rubrique de référence



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=rprf_ejbcontainer
Nom du fichier : rprf_ejbcontainer.html