EJB container tuning

EJB container tuning

If we use applications that affect the size of the EJB container cache, it is possible that the performance of the applications can be affected by an incorrect size setting. Container managed persistence (CMP) is discussed in this topic; although it is important to know that entity beans are not supported in an EJB 3.x module.

EJB cache size

Monitor Tivoli Performance Viewer to diagnose whether the EJB container cache size setting is tuned correctly for the application.

If the application has filled the cache causing evictions to occur, Tivoli Performance Viewer shows a high rate of the ejbStores method being called and probably a lower than expected processor utilization on the workstation machine.

All applications that use enterprise beans must have this setting adjusted from the default value, if the following formula result equals more than 2000:
EJB_Cache_Size = (Largest number of Option B or C entity beans enlisted in a 
transaction * maximum number of concurrent transactions) + 
(Largest number of unique Option A entity beans expected to be accessed during 
typical application workload) + 
(Number of stateful session beans active during typical workload) + 
(Number of stateless session bean types used during typical workload)

Where:
Option B and C entity beans are only held in the EJB cache during the lifetime 
of the transaction they are enlisted in. Therefore, the first term in the formula 
computes the average EJB cache requirements for these types of beans.

Option A entity beans are held in the EJB cache indefinitely, and are only removed
 from the cache if there starts to become more beans in the cache than the cache 
size has been set to. If the application uses Read Only Beans, consider them to be 
Option A beans for this tuning calculation. 

Stateful session beans are held in the EJB cache until they are removed by the 
application, or until their session timeout value is reached.

Only a single stateless session bean instance for each EJB type is held in the 
cache during the time any methods are running on that stateless session 
bean. If two or more methods are being implemented simultaneously on the same 
stateless session bean type, each method runs on its own bean instance, but 
only one cache location is used for all of these instances. 
This formula calculates the upper bound on the maximum number of enterprise beans active at one time inside the application server. Because the cache of the EJB container is built to contain all these beans for performance optimizations, best performance can be achieved by setting this cache size to be larger than the number resulting from the previous formula.

We can set the EJB cache size in the administrative console under Servers > Server Types > WebSphere application servers > server > EJB Container Settings > EJB cache settings.

Also, while adjusting the EJB cache size, we can tune the EJB container management thread parameter to meet the needs of the application. The management thread is controlled through the Cleanup interval setting. This setting controls how frequently a daemon thread inside of the product attempts to remove bean instances from the cache that have not been used recently, attempting to keep the number of bean instances at or below the cache size. This behavior ensures that the EJB container places and looks up items in the cache quickly. Leave this interval set to the default; however, in some cases, it might be worthwhile to see if there is a benefit to reducing this interval.

For information about tuning the EJB cache using the EJB cache trace service, read about tuning the EJB cache and using the trace service.

EJB stateful session bean tuning

Stateful session bean timeout is configured in different ways, with different scopes, depending on the version of WebSphere Application Server.

WAS v6.1 and earlier supports configuration of stateful session bean timeout, per bean, using the ibm-ejb-jar-ext.xmi file.

WAS v7.0 supports configuration of stateful session bean timeout, per bean, using the ibm-ejb-jar-ext.xmi file (for EJB 2.x modules), and the ibm-ejb-jar-ext.xml file (for EJB 3.x modules).

WAS v8.x supports configuration of stateful session bean timeout, per bean, using the ibm-ejb-jar-ext.xmi (for EJB 2.x modules) and the ibm-ejb-jar-ext.xml (for EJB 3.x modules) files, and the stateful-timeout XML element and the @StatefulTimeout annotation. Additionally, we can configure a server-wide (global) stateful session timeout value using the com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout system property.

For IBM extension and binding files, the .xmi or .xml file name extension is different depending on whether we are using a pre-Java EE 5 application or module or a Java EE 5 or later application or module. An IBM extension or binding file is named ibm-*-ext.xmi or ibm-*-bnd.xmi where * is the type of extension or binding file such as app, application, ejb-jar, or web. The following conditions apply:

For an application or module that uses a Java EE version prior to version 5, the file extension must be .xmi.
For an application or module that uses Java EE 5 or later, the file extension must be .xml. If .xmi files are included with the application or module, the product ignores the .xmi files.

However, a Java EE 5 or later module can exist within an application that includes pre-Java EE 5 files and uses the .xmi file name extension.

The ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, and ibm-portlet-ext.xmi files continue to use the .xmi file extensions.

Stateless session beans do not have a timeout value because they have no conversational state and are not dedicated to any specific client.

Use Rational Application Developer to update the ibm-ejb-jar-ext.xmi file, which is used to configure the stateful session timeout value for beans in an EJB 2.x module. See defining session timeout settings for a bean in the Rational Application Developer Information Center.

For example, the generated XMI code to set a stateful session timeout value of 15 minutes is:
<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension_1"
  timeout="15">
We can modify the ibm-ejb-jar-ext.xml file to set the stateful session timeout for beans in an EJB 3.x module. For example, the code to set a stateful session timeout value to 15 minutes for the myBean bean is:
<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension"
  timeout="15">
    <enterpriseBean xmi:type="ejb:Session" href="META-INF/ejb-jar.xml#MyBean"/>
 </ejbExtensions>
We can configure stateful session bean timeout using the @StatefulTimeout annotation. The @StatefulTimeout annotation takes a required value parameter representing the duration of the timeout, and an optional unit parameter. If the optional unit parameter is not specified, the default unit is minutes. The @StatefulTimeout annotation is introduced as part of EJB 3.1.

For example, use the @StatefulTimeout annotation to declare a timeout value of 100 seconds:
@StatefulTimeout(value=100 unit=java.util.concurrent.TimeUnit.SECONDS)
We can configure stateful session bean timeout using the stateful-timeout XML element in the ejb-jar.xml deployment descriptor. The stateful-timeout element is introduced as part of EJB 3.1.

For example, to set a timeout value of 100 seconds:
<stateful-timeout>
     <timeout>100</timeout>
     <unit>Seconds</unit>
</stateful-timeout>
The @StatefulTimeout annotation and the stateful-timeout XML element are the specification-defined mechanisms for declaring timeout values per bean, beginning with EJB 3.1. Prior to EJB 3.1, there is no specification-defined way for declaring stateful session timeout per bean. When using the stateful-timeout XML element or @StatefulTimeout annotation, a value of -1 means that the bean never times out, and a value of 0 means that the bean is immediately eligible for removal.

We can configure stateful session bean timeout on a global (server-wide) basis, using the com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout system property. The unit of time for the com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout is minutes. The specified value must be 0 or greater, and if an invalid value is specified, the default value of 10 minutes is used instead. The global timeout value cannot be configured using XML or annotations. The global timeout value applies to all stateful session beans running in the server, including stateful session beans in EJB 2.x or EJB 3.x modules.

In WAS v8.x, bean-level stateful timeout settings take precedence over the server-wide timeout setting. The server-wide timeout setting takes precedence over the default (unspecified) timeout. The following order of precedence is used to determine the stateful session timeout value for a bean running in WAS v8.x:

stateful-timeout XML element
@StatefulTimeout annotation
ibm-ejb-jar-ext.xml or ibm-ejb-jar-ext.xmi
com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout system property
If no bean-level or server-wide timeout value is explicitly specified, then the default timeout value of 10 minutes is applied.

Dcom.ibm.websphere.ejbcontainer.poolSize

If the application is using most bean instances in the pool, the Tivoli Performance Viewer indicates this. When the majority of the bean instances are used, increase the size of those bean pools that are being exhausted by adding this parameter to the generic JVM arguments; for example:
-Dcom.ibm.websphere.ejbcontainer.poolSize=<application_name>#<module_name>#
<enterprisebean_name>=<minSize>,<maxSize>
Where:

The <application_name> element is the Java EE application name as defined in the EAR file deployment descriptor, for the bean whose pool size is being set.

The <module_name> element is the JAR file name of the EJB module, for the bean whose pool size is being set.

The <bean_name> element is the Java EE enterprise bean name as defined in the EJB module deployment descriptor, for the bean whose pool size is being set

The <minSize> element is the number of bean instances the container maintains in the pool, irrespective of how long the beans have been in the pool (beans greater than this number are cleared from the pool over time to optimize memory usage)

The <maxSize> element is the number of bean instances in the pool where no more bean instances are placed in the pool once they are used (that is, when the pool is at this size, any additional beans are discarded rather than added into the pool, which ensures the number of beans in the pool have an upper limit so that memory usage does not grow in an unbounded way).

To keep the number of instances in the pool at a fixed size, the minSize and maxSize elements can be set to the same number. A separate instance pool for every EJB type running in the application server exists, and that every pool starts out with no instances; the number of instances grow as beans are used and then placed in the pool.

When a bean instance is needed by the container and no beans are available in the pool, the container creates a bean instance, uses it, then places that instance in the pool, unless there are already maxSize instances in the pool. For example, the statement
Dcom.ibm.websphere.ejbcontainer.poolSize=ivtApp#ivtEJB.jar#ivtEJBObject=125,1327  
would set a minSize of 125 and a maxSize of 1327 on the bean named ivtEJBObject within the ivtEJB.jar file, in the application ivtApp.
The application, ivtApp, is replaced by the actual application name, the ivtEJB.jar file is replaced by the JAR file containing the bean that must have its pool size increased, and ivtEJBObject is the bean name of the enterprise bean whose pool size must be increased. The minimum number of beans that are held in the pool is 125. The maximum number of beans that are held in the pool is 1327. Set these so that no more evictions occur from the pool. In most cases these must be set equal if memory is plentiful because no growth and shrinkage of the pool occurs.

Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation

We must understand how the application handles the creation of primary key objects for use by CMP beans and bean-managed persistence (BMP) beans inside of the product.

The EJB container uses the primary key of an entity bean as an identifier inside of internal data structures to optimize performance. However, the EJB container must copy these primary key objects upon the first access to the bean to ensure that the objects stored in the internal caches are separate from the ones used in an application. This process occurs to keep the internal structures consistent in case the application changes or mutates the primary key. If the application does not mutate any of the primary keys used to create and access entity beans once they are created, a special flag can be used that ensures that the EJB container skips the copy of the primary key object, saving processor cycles, and increasing performance. This mechanism can be enabled at our own risk by adding the -D property to the generic JVM arguments field.
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true
Entity beans are not supported in EJB 3.x and later modules.
The performance benefit of this optimization depends on the application. If the application uses primitive types for the primary keys of enterprise beans, there is no gain because these objects are already immutable and the copy mechanism takes this into account. If, however, the application uses many complex primary keys, that is, an object for a primary key or multiple fields, this parameter can yield significant improvements.

Dcom.ibm.ws.pm.deferredcreate

The persistence manager is used by the EJB container to persist data to the database from CMP entity beans.

When creating entity beans by calling the ejbCreate method, by default the persistence manager immediately inserts the empty row with only the primary key in the database. In most cases, once creating the bean we must modify fields in the bean created or in other beans inside of the same transaction. To postpone the insert into the database until the end of the transaction to eliminate one trip to the database, set the -D flag inside of the JVM custom properties field. The data is inserted into the database and consistency is maintained.
Entity beans are not supported in EJB 3.x and later modules.
-Dcom.ibm.ws.pm.deferredcreate=true
The performance benefit of this optimization depends on the application. If the EJB applications transactions are insert intensive, the application can benefit from this optimization. If the application performs few inserts, the benefit of this optimization is less.

Dcom.ibm.ws.pm.batch

When an EJB application accesses multiple CMP beans inside of a single transaction, depending on the operations performed on the beans, such as updates, inserts, and reads, the number of operations issued to the database corresponds directly to the operations performed on the CMP beans. If the database system we are using supports batching of update statements, we can enable this flag and increase performance on all interactions with the database that involve more than two updates in a single transaction.

Entity beans are not supported in EJB 3.x and later modules.
Use this flag, which supports the persistence manager adding all the update statements into one single batch statement that is issued to the database. This process saves round trips to the database, which increases performance. If we know that the application exhibits the behavior of updating multiple CMP beans in a single transaction, and the database supports batch updates, we can set the -D flag inside of the JVM custom properties field; for example:
-Dcom.ibm.ws.pm.batch=true
The performance benefit of this optimization depends on the application. If the application never or infrequently updates CMP beans, or updates only a single bean per transaction, there is no performance gain. If the application updates multiple beans per transaction, this parameter benefits the applications performance.

The following table lists the backend databases that support batch update.

Database Supports batch update Supports batch update with Optimistic Concurrency Control
DB2 yes no
Oracle yes no
DB2 Universal Driver yes yes
Informix yes yes
SQLServer yes yes
Apache Derby yes yes

Batch update with OCC cannot be performed for databases that do not support it, even if specified by the access intent.

com.ibm.ws.pm.useLegacyCache

Name of the Java class that the product uses to implement the javax.rmi.CORBA.UtilDelegate interface.

Entity beans are not supported in EJB 3.x and later modules.
Persistence manager has two types of caching mechanisms, legacy cache and two-level cache. Typically, two-level cache is more efficient than legacy cache because of optimizations in this mode. The default is legacy cache, although two-level cache is recommended. Set this configuration through the system property as follows:
com.ibm.ws.pm.useLegacyCache=false
com.ibm.ws.pm.grouppartialupdate and com.ibm.ws.pm.batch

The partial updates feature enhances the performance of applications with enterprise beans in certain scenarios. Persistence manager has two caching mechanisms available, legacy cache and two-level cache. Typically, two-level cache performs better than legacy cache because of the optimizations in this mode.

Entity beans are not supported in EJB 3.x and later modules.
In certain applications where we must perform both batch updates and partial updates, configure the following system properties to gain the benefits of both:
'com.ibm.ws.pm.grouppartialupdate=true' and 'com.ibm.ws.pm.batch=true'
Related:

EJB containers
Tune the application serving environment
Manage EJB containers
Task overview: Using enterprise beans in applications
Tune EJB cache with trace service
http://pic.dhe.ibm.com/infocenter/radhelp/v9/topic/com.ibm.j2ee.doc/topics/tsessiontimeout.html

Database	Supports batch update	Supports batch update with Optimistic Concurrency Control
DB2	yes	no
Oracle	yes	no
DB2 Universal Driver	yes	yes
Informix	yes	yes
SQLServer	yes	yes
Apache Derby	yes	yes