EJB container
After the EJB container is deployed, you can use the following parameters to make adjustments that improve performance.
Cache settings (Cache size and Cleanup interval)
To determine the cache absolute limit, multiply the number of enterprise beans active in any given transaction by the total number of concurrent transactions expected. Then, add the number of active session bean instances. Use the Tivoli Performance Viewer to view bean performance information. The cache settings consist of two parameters: the cache size and the cleanup interval.
The cleanup interval specifies the interval at which the container attempts to remove unused items from the cache in order to reduce the total number of items to the value of the cache size.
The cache size specifies the number of buckets in the active instance list within the EJB container.
To change these settings, click Servers -> Application Servers -> <ServerName> -> EJB Container -> EJB Cache Settings (from the Additional Properties pane).
The default values are Cache size=2053 and Cache cleanup interval=3000 milliseconds.
ORB thread pool size
Method invocations to enterprise beans are only queued for requests coming from remote clients going through the RMI activity service. An example of such a client is an EJB client running in a separate Java Virtual Machine (another address space) from the enterprise bean. In contrast, no queuing occurs if the EJB client (either a servlet or another enterprise bean) is installed in the same JVM that the EJB method runs on and the same thread of execution as the EJB client.
Remote enterprise beans communicate by using the RMI/IIOP protocol. Method invocations initiated over RMI/IIOP are processed by a server-side ORB. The thread pool acts as a queue for incoming requests. However, if a remote method request is issued and there are no more available threads in the thread pool, a new thread is created. After the method request completes, the thread is destroyed. Therefore, when the ORB is used to process remote method requests, the EJB container is an open queue, due to the use of unbounded threads.
Tivoli Performance Viewer can help tune the ORB thread pool size settings. Use a standard workload that represents a typical number of incoming client requests, use a fixed number of iterations, and use a standard set of configuration settings. Watch the Percent Maxed counter of the Object Request Broker submodule of the Thread Pools module. If the value of this counter is consistently in the double digits, then the ORB could be a bottleneck and the number of threads in the pool should be increased.
The degree to which the ORB thread pool value needs to be increased is a function of the number of simultaneous servlets (that is, clients) calling enterprise beans and the duration of each method call. If the method calls are longer or the applications spend a lot of time in the ORB, consider making the ORB thread pool size equal to the Web container size. If the servlet makes only short-lived or quick calls to the ORB, servlets can potentially reuse the same ORB thread. In this case, the ORB thread pool can be small, perhaps even one-half of the thread pool size setting of the Web container.
The ORB thread pool size is configured from the Administrative Console using these steps:
1. Select Servers -> Application Servers in the console navigation tree. 2. Select the name of the appserver from the list of application servers in the workspace. 3. Select the ORB Service entry in the Additional Properties pane of the workspace. 4. Select Thread Pool in the Additional Properties pane of the workspace. 5. Use the Maximum Size field to configure the maximum pool size. Note that this only affects the number of threads held in the pool (the actual number of ORB threads can be higher). 6. Save the configuration and restart the affected appserver for the change to take effect. Some additional settings related to the ORB can also be tuned. These are explained in 19.4.12, Object Request Broker (ORB).
Break CMP enterprise beans into several enterprise bean modules during assembly
To increase performance, break CMP enterprise beans into several enterprise bean modules during assembly. The load time for hundreds of beans can be improved by distributing the beans across several JAR files and packaging them to an EAR file. This is faster when the administrative server attempts to start the beans, for example 8-10 minutes versus more than one hour when one JAR file is used.
Prev | Home | Next WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.