GlassFish Thread Pool Test

The Virtual Machine for the Java platform (Java Virtual Machine) or JVM machine) can support many threads of execution simultaneously. To help performance, GlassFish Server maintains one or more thread pools. It is possible to assign specific thread pools to connector modules, to network listeners, or to the Object Request Broker (ORB).

One thread pool can serve multiple connector modules and enterprise beans. Request threads handle user requests for application components. When GlassFish Server receives a request, it assigns the request to a free thread from the thread pool. The thread executes the client's requests and returns results.

Administrators will have to continuously observe the request load on their applications, periodically check how the thread pool services these requests, and accordingly decide whether/not to resize the thread pool commensurate to the current and anticipated load. The GlassFish Thread Pool test provides administrators with the load and thread pool usage insights they require to take these crucial sizing decisions.

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 thread pool 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
Core threads	Indicates the number of core threads currently in this pool.	Number
Current threads	Indicates the current number of threads in this pool.	Number
Current busy threads	Indicates the number of threads in this pool that are currently processing requests.	Number	A high value for this measure is indicative of a high load on this applications deployed on the GlassFish application server. This measure is also useful for determining usage trends. For example, it can show the time of day and the day of the week in which you usually reach peak thread count. In addition, the creation of too many threads can result in out of memory errors or thrashing. By watching this metric, you can reduce excessive memory consumption before it’s too late.
Maximum threads	Indicates the maximum number of threads allowed in this thread pool.	Number	This measure reports the value of the Max Thread Pool Size parameter of the GlassFish Enterprise server. This parameter specifies the maximum number of simultaneous requests the server can handle. The default value is 5. When the server has reached the limit or request threads, it defers processing new requests until the number of active requests drops below the maximum amount. Increasing this value will reduce HTTP response latency times.
Total executed tasks	Indicates the total number of tasks executed by the threads in this pool during the last measurement period.	Number	This measure is a good indicator of how busy the pool was during the last measurement period.
Thread busy	Indicates the percentage of threads in this pool that are currently in use.	Percent	This measure is computed using the following formula: (Current busy threads / Maximum threads)*100 A high value is indicative of a busy pool. A value close to 100% indicates excessive utilization of threads in a pool. If the value of this measure grows closer to 100% over time, it indicates that the pool is rapidly running out of threads to service the request load. You may then have to fine-tune the thread pool size using the Max Thread Pool Size parameter and the Min Thread Pool Size parameter. The Max Thread Pool Size parameter specifies the maximum number of simultaneous requests the server can handle. The default value is 5. When the server has reached the limit or request threads, it defers processing new requests until the number of active requests drops below the maximum amount. Increasing this value will reduce HTTP response latency times. In practice, clients frequently connect to the server and then do not complete their requests. In these cases, the server waits a length of time specified by the Timeout parameter. Also, some sites do heavyweight transactions that take minutes to complete. Both of these factors add to the maximum simultaneous requests that are required. If your site is processing many requests that take many seconds, you might need to increase the number of maximum simultaneous requests. Adjust the thread count value based on your load and the length of time for an average request. In general, increase this number if you have idle CPU time and requests that are pending; decrease it if the CPU becomes overloaded. Suitable Request Max Thread Pool Size values range from 100 to 500, depending on the load. If your system has extra CPU cycles, keep incrementally increasing thread count and monitor performance after each incremental increase. When performance saturates (stops improving), then stop increasing thread count. The Min Thread Pool Size property specifies the minimum number of threads the server initiates upon startup. The default value is 2. Min Thread Pool Size represents a hard limit for the maximum number of active threads that can run simultaneously, which can become a bottleneck for performance. Specifying the same value for minimum and maximum threads allows GlassFish Server to use a slightly more optimized thread pool. This configuration should be considered unless the load on the server varies quite significantly.
Pool utilization	Indicates the percentage of threads in the pool that are active.	Percent	This measure is computed as a ratio of the value of the Current threads measure and the Maximum threads measure.