GlassFish EJB Cache Statistics

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.

Target of the test : A GlassFish server

Agent deploying the test : An internal/remote agent

Outputs of the test : One set of results for each cache configured on the GlassFish Enterprise server being monitored.

Configurable parameters for the test
Parameters	Description
Test Period	How often should the test be executed.
Host	The host for which the test is to be configured.
Port	The port number at which the specified host listens
JMX Remote Port	To collect metrics from a GlassFish Enterprise server, the eG agent monitoring that server should be configured to use JMX to connect to the JRE used by the server and pull out the metrics of interest. By default, JMX support is enabled for the JRE used by the GlassFish Enterprise Server. The JMX connector listens on port 8686 by default. Therefore, type 8686 as the JMX Remote Port. If JMX listens on a different port in your environment, then specify the same here. To know the port at which JMX listens, open the domain.xml file in the <GLASSFISH_INSTALL_DIR>\Sun\AppServer\domains\domain1\config directory and look for the code block shown below: <jmx-connector accept-all="false" address="0.0.0.0" auth-realm-name="admin-realm" enabled="true" name="system" port="8686" protocol="rmi_jrmp" security-enabled="false"> The port number specified against the Port parameter in the code block above refers to the JMX Remote Port.
JMX User, JMX Password, and Confirm Password	By default, the JMX connector on the GlassFish Enterprise Server requires authentication. To enable the eG agent to use JMX therefore, you need to configure the agent with the credentials of a user who is authorized to use JMX. Typically, the GlassFish administrator has the right to use JMX. You can hence configure the JMX User and JMX Password parameters with the credentials of the administrator. However, if you prefer not to expose the credentials of an administrator owing to security considerations, you can use the credentials of any other user with access rights to JMX. To know the name of such a user, open the domain.xml file in the <GLASSFISH_INSTALL_DIR>\Sun\AppServer\domains\domain1\config directory and look for the code block shown below: <jmx-connector accept-all="false" address="0.0.0.0" auth-realm-name="admin-realm" enabled="true" name="system" port="8686" protocol="rmi_jrmp" security-enabled="false"> The user name specified against the auth-realm-name parameter in the code block above can be configured as the JMX User, and the Password of that user can be specified against JMX Password. Confirm the JMX Password you specify by retyping that password in the Confirm Password text box.
JNDIName	The JNDIName is a lookup name for connecting to the JMX connector. By default, this is jmxrmi. If you have registered the JMX connector in the RMI registry using a different lookup name, then you can change this default value to reflect the same.
JMX Provider	This test uses a JMX Provider to access the MBean attributes of the GlassFish Enterprise server and collect metrics. Specify the package name of this JMX Provider here. By default, this is set to com.sun.jmx.remote.protocol.
Timeout	Specify the duration (in seconds) for which this test should wait for a response from the GlassFish Enterprise server. If there is no response from the server beyond the configured duration, the test will timeout. By default, this is set to 240 seconds.

Measurements made by the test
Measurement	Description	Measurement Unit	Interpretation
Total beans in cache	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.
StatefulSessionBean 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.
Passivations success	Indicates the number of passivations that suceeded currently in this cache.	Number
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.
Removed sessions	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.