EJB 2.1 container tuning

If you use applications that affect the size of the Enterprise JavaBeans™ (EJB) container cache, it is possible that the performance of your applications can be impacted 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.0 module.




Related concepts
EJB containers

EJB cache size

Monitoring Tivoli® Performance Viewer (TPV) is a great way to diagnose if the EJB container cache size setting is tuned correctly for your application.

If the application has filled the cache causing evictions to occur, TPV will show a very high rate of the ejbStores method being called and probably a lower than expected CPU utilization on the application server machine.

All applications using enterprise beans should have this setting adjusted from the default if the following formula works out to 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 SessionBean 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 your application uses Read Only Beans, consider them to be Option A beans for the purpose of this tuning calculation. 

Stateful Session Beans are held in the EJB cache until they are removed by the 
application, or 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 being executed on that stateless Session 
Bean. If two or more methods are being executed simultaneously on the same 
stateless Session Bean type, each method executes on its own bean instance, but 
only one cache location is used for all of these instances. 

This calculates the upper bound on the maximum possible number of enterprise beans active at one time inside the application server. Because the EJB container's cache 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 calculation above.

<tuning parameter>
This setting can be found under Servers > Application Servers > serverName > 
         EJB Container > EJB Cache Settings

Also while adjusting the EJB cache size, the EJB container management thread parameter can be tuned to meet the needs of the application. The management thread is controlled through the Clean Up 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 ensures that the EJB container places and looks up items in the cache as quickly. It is typically best to 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 to an even finer degree using the EJB cache trace service, see the topic Tuning the EJB cache and using the trace service.

EJB stateful session bean tuning

Stateful session bean timeout values can be configured using an assembly tool. For WebSphere® Application Server Version 5.1 and later, the default value is 600 seconds. If this default value is not acceptable, you can change it in the tooling's EJB deployment descriptor editor. Stateless session beans do not have a timeout value because they have no conversational state and are not dedicated to any specific client.

You cannot set the timeout value globally, or on the server, so that the value applies to all stateful session beans. You can only set the timeout on a bean-by-bean basis.

Dcom.ibm.websphere.ejbcontainer.poolSize

If the application is using the majority of the instances in the pool, the TPV indicates this. When this occurs, then the size of those bean pools that are being exhausted should be increased. This can be done by adding this parameter in the JVM's custom properties tag .

-Dcom.ibm.websphere.ejbcontainer.poolSize=<application_name>#<module_name>#
<enterprisebean_name>=<minSize>,<maxSize>

where:
 <application_name> is the J2EE application name as defined in the application 
archive (.ear) file deployment descriptor, for the bean whose pool size is being 
set

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

<bean_name> is the J2EE Enterprise Bean name as defined in the EJB module 
deployment descriptor, for the bean whose pool size is being set

<minSize> 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)

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

To keep the number of instances in the pool at a fixed size, minSize and maxSize 
can be set to the same number. Note that there is a separate instance pool for 
every EJB type running in the application server, and that every pool starts out
with no instances in it - that is, the number of instances grows 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 new 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". 
Where ivtApp is replaced by the actual application name, ivtEJB.jar file is replaced by the JAR that contains the bean that needs to have its pool size increased, and ivtEJBObject is the bean name of the enterprise bean whose pool size should 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. These should be set so no more evictions occur from the pool and in most cases should be set equal if memory is plentiful because no growth and shrinkage of the pool occurs.

Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation

You should have a good idea of how your application handles the creation of primary key objects for use by CMP beans and bean-managed persistence (BMP) beans inside of the product. The IBM® EJB container uses the primary key of an entity bean as an identifier inside of many 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, in case the application changes or mutates the primary key, to keep the internal structures consistent. If the application does not mutate any of the primary keys used to create and access entity beans after they are created, a special flag can be used that ensures the EJB container skips the copy of the primary key object, saving CPU cycles and increasing performance. This mechanism can be enabled at your own risk by adding the –D property to the JVM custom property field.

<tuning parameter>
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true

The performance benefit of this optimization depends on the application. If the application uses primitive types for enterprise beans' primary keys 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, after creating the bean you should modify fields in the bean created or in other beans inside of the same transaction. If you want 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.

<tuning parameter>
-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, reads, the number of operations issued to the database corresponds directly to the operations performed on the CMP beans. If the database system you are using supports batching of update statements, you can enable this flag and increase performance on all interactions with the database that involve more than two updates in a single transaction.

This flag lets the persistence manager add all the update statements into one single batch statement that is issued to the database. This saves round trips to the database, increasing performance. If the you know that your application exhibits the behavior of updating multiple CMP beans in a single transaction, and the database supports batch updates, you can set the –D flag inside of the JVM custom properties field.

<tuning parameter>
-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 only updates a single bean per transaction there is no performance gain. If the application updates multiple beans per transaction, this parameter benefits the applications performance.
Table 1. Backend databases that support batch update. 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
Note: 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

Specifies the name of the Java™ class that the product uses to implement the javax.rmi.CORBA.UtilDelegate interface.

Persistence manager has two types of caching mechanisms, legacy cache and two-level cache. Typically, two-level cache performs better 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
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.

In certain applications where you need to perform both batch updates and partial updates, you must configure the following system properties to gain the benefits of both:
‘com.ibm.ws.pm.grouppartialupdate=true' and ‘com.ibm.ws.pm.batch=true'

Reference topic    

Terms of Use | Feedback

Last updated: Oct 21, 2010 1:44:59 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-express-dist&topic=rprf_ejbcontainer
File name: rprf_ejbcontainer.html