|
Measures reported by GfEjbBeanPoolTest
A bean in the pool represents the pooled state in the EJB lifecycle. This means that the bean does not have an identity. The advantage of having beans in the pool is that the time to create a bean can be saved for a request. The container has mechanisms that create pool objects in the background, to save the time of bean creation on the request path.
Stateless session beans and entity beans use the EJB pool. By continuously monitoring the usage of these beans in the pools, you can accurately isolate the pools that are over-utilized - i.e., pools that do not enough free beans to service future requests - and under-utilized - i.e., pools that have too many beans than required. This test enables administrators to achieve the same. Based on the usage reports of this test, administrators can tune the pool size, so that abnormal usage patterns can be avoided.
The measures made by this test are as follows:
| Measurement |
Description |
Measurement Unit |
Interpretation |
| Num_beans_in_pool |
Indicates the number of beans that are currently available in this pool. |
Number |
|
| Num_threads_waiting |
Indicates the number of threads that are currently waiting for a free bean in this pool. |
Number |
A well-tuned pool is one that has enough free beans to service all user requests, and does not keep any request thread waiting for a free bean. Ideally therefore, this measure should report the value 0 for a pool. A non-zero value indicates that the corresponding pool is running out of beans. This could be because the pool is improperly sized. You may then have to resize the pool. For this, you can use any of the following parameters:
- steady-pool-size: This governs the initial and minimum number of beans maintained in the pool. Set this property to a number greater than zero for a moderately loaded system. Having a value greater than zero ensures that there is always a pooled instance to process an incoming request.
- max-pool-size: This governs the maximum number of connections that can be created to satisfy client requests. Set this property to be representative of the anticipated high load of the system. An very large pool wastes memory and can slow down the system. A very small pool is also inefficient due to contention.
- resize-quantity: This governs the number of beans to be created or deleted in the pool when the requests are being serviced by the server. Be sure to re-calibrate the pool resize quantity when you change the maximum pool size, to maintain an equilibrium. Generally, a larger maximum pool size should have a larger pool resize quantity.
|
| Jms_max_messages_load |
Indicates the number of messages that are currently loaded into a JMS session in this pool during the last measurement period. |
Number |
The message-driven bean container uses the JMS service integrated into the GlassFish Server for message-driven beans that are JMS clients. The container manages a pool of message-driven beans for the concurrent processing of a stream of messages. A message-driven bean is a client to a Connector inbound resource adapter. |
| Total_beans_created |
Indicates the number of beans created in this pool during the last measurement period. |
Number |
|
| Total_beans_destroyed |
Indicates the number of beans destroyed in this pool during the last measurement period. |
Number |
If one/more beans in a pool violate the pool-idle-timeout-in-seconds setting of that pool - i.e., if the beans were idle for a duration longer than the pool-idle-timeout-in-seconds configuration - then such beans are destroyed, provided they are stateless session beans or message driver beans. |
|