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.
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
.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.

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.
sptcfgLes 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.
<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.
- Elément XML stateful-timeout
- Annotation @StatefulTimeout
- ibm-ejb-jar-ext.xml ou ibm-ejb-jar-ext.xmi
- Propriété système com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout
- 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.
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.
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true

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.

-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.

-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.
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 |

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.

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.

'com.ibm.ws.pm.grouppartialupdate=true' and 'com.ibm.ws.pm.batch=true'