eG Monitoring
 

Measures reported by GfEjbBeanCacheTest

To improve the performance and the scalability of the EJB container, the GlassFish server caches EJBs. A bean in the cache represents the ready state in the EJB lifecycle. This means that the bean has an identity (for example, a primary key or session ID) associated with it.

Beans moving out of the cache have to be passivated or destroyed according to the EJB lifecycle. Once passivated, a bean has to be activated to come back into the cache.

Any incoming request using these “ready” beans from the cache avoids the overhead of creation, setting identity, and potentially activation. It is hence good to cache as many beans as possible.

Using this test, you can monitor the usage of the EJB cache and accurately identify caches that are grossly under-utilized. You can also diagnose the probable cause for the ineffective cache utilization - is it because adequate beans are not available in the cache? if so, why? - is it because the cache size is too small and needs to be resized to accommodate more beans or to reduce cache overflow? In the process, you can even determine the success/failure of stateful session bean passivation attempts.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Total_cache_beans Indicates the number of EJBs in this EJB cache. Number  
Cache_hits Indicates current number of hits in this EJB Cache. Number A high value is desired for this measure. A low value indicates that adequate beans are not available in the cache to service requests to the server. This in turn could increase the processing overheads of the requests to the server.
Cache_misses Indicates the number of times a current user request failed to find an EJB in this EJB cache instance. Number A low value is desired for this measure.
Cache_hits_ratio Indicates the percentage of user requests that were serviced by the beans in this cache. Percent A high value is desired for this measure. A low value indicates that adequate beans are not available in the cache to service requests to the server. This in turn could increase the processing overheads of the requests to the server.

Under such circumstances, you may want to alter the size of the cache by modifying the max-cache-size and resize-quantity parameters. The max-cache-size governs the maximum number of beans in the cache. Increasing this size can increase the capacity of the cache, and thus enable it to hold additional beans. In case of entity beans, you need to tune this parameter depending on the usage of a particular entity bean. While beans that are used less (for example, an order that is created and never used after the transaction is over) are to be cached less, the beans that are used frequently (for example, an item in the inventory that gets referenced very often), are to be cached more in numbers. The resize-quantity governs the number of beans to be created or deleted when the cache is serviced by the server. By increasing this quantity, you can ensure that additional beans are created to serve additional user requests.

Num_passivations Indicates the number of StatefulSessionBean passivations that are currently occurring in this cache. Number Beans moving out of the cache have to be passivated or destroyed according to the EJB lifecycle. Once passivated, a bean has to be activated to come back into the cache. Typically, bean passivation occurs when the max-cache-size setting is exceeded and the cache overflows. A bean is also passivated if it outlives the cache-idle-timeout-in-seconds settings.
Num_passivations_success Indicates the number of passivations that suceeded currently in this cache. Number  
Num_passivations_errors Indicates the number of errors that occurred when passivating the beans in this cache. Number Ideally, the value of this measure should be 0.
Num_expired_sessions_removed Indicates the number of expired session beans that were currently removed from this cache. Number If a stateful session bean remains idle in the backup store for a duration beyond the configured removal-timeout-in-seconds, then it is removed from the backup store and will not be accessible to the client. The default value is 60 minutes.