WebLogic Thread Pools Test

Starting from WebLogic server release 9.0, every server instance uses a self-tuned thread-pool. All requests, whether related to system administration or application activity are processed by this single thread pool. The self-tuning thread pool would also adjust its pool size automatically based on the throughput history that WLS gathers every 2 seconds and based on queue size.

This test monitors how the self-tuning thread pool is being used, and in the process reports whether there are adequate idle threads in the pool to handle additional workload that may be imposed on the WebLogic server. The test also turns the spot light on the request (if any) that is hogging threads, and enables you to quickly capture a sudden/consistent increase in queue size, which in turn might impact the pool size.

Target of the test : A WebLogic Application Server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for the self-tuning thread pool on the WebLogic server being monitored.

Configurable parameters for the test
Parameter Description

Test period

How often should the test be executed

Host

The IP address of the WebLogic server.

Port

The port number of the WebLogic server.

AdminServerHost and AdminServerPort

In some highly secured environments, the eG agent may not be able to collect certain critical metrics related to JDBC from a managed WebLogic server. In such cases, to enable the eG agent to collect the required metrics, you should specify the IP address and Port of the WebLogic admin server to which the managed WebLogic server is associated with. This will enable the eG agent to connect to the WebLogic admin server and collect the required metrics pertaining to the managed WebLogic server. Specify the IP address and Port of the WebLogic admin server in the AdminServerHost and AdminServerPort text boxes. By default, these parameters are set to none.

JSPTimeOut

Specify the duration (in seconds) within which the eG agent should receive the response from the eGurkha WAR file deployed on the WebLogic server in this text box. By default, this is set to is 120 seconds.

User

The admin user name of the WebLogic server being monitored.

Password

The password of the specified admin user.

Confirm Password

Confirm the password by retyping it here.

EncryptPass

If the specified password needs to be encrypted, set the EncryptPass flag to Yes. Otherwise, set it to No. By default, the Yes option will be selected.

Note:

If the UseWarFile flag is set to No, then make sure that the EncryptPass flag is also set to No.

SSL

Indicate whether the SSL (Secured Socket Layer) is to be used to connect to the WebLogic server.

Server

The name of the specific server instance to be monitored for a WebLogic server (the default value is "localhome")

URL

The URL to be accessed to collect metrics pertaining to the WebLogic server. By default, this test connects to a managed WebLogic server and attempts to obtain the metrics of interest by accessing the local Mbeans of the server. This parameter can be changed to a value of http://<adminserverIP>:<adminserverPort>. In this case, the test connects to the WebLogic admin server to collect metrics pertaining to the managed server (specified by the HOSTand PORT). The URL setting provides the administrator with the flexibility of determining the WebLogic monitoring configuration to use.

Note:

If the admin server is to be used for collecting measures for all the managed WebLogic servers, then it is mandatory that the egurkha war file is deployed to the admin server, and it is up and running. 

Version

The Version textbox indicates the version of the Weblogic server to be managed. The default value is "none", in which case the test auto-discovers the weblogic version. If the value of this parameter is not "none", the test uses the value provided (e.g., 7.0) as the weblogic version (i.e., it does not auto-discover the weblogic server version). This parameter has been added to address cases when the eG agent is not able to discover the WebLogic server version.

UserWarFile

This flag indicates whether/not monitoring is to be done using a Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS is used by the server to connect to the server). If this flag is set to No, the agent directly connects to the WebLogic server using the T3 protocol (no other file needs to be deployed on the WebLogic server for this to work). Note that the T3 protocol-based support is available for WebLogic servers ver.9 and above. Also, if the UserWarFile parameter is set to No, make sure that the EncryptPass parameter is set to No as well.  

When monitoring a WebLogic server deployed on a Unix platform particularly, if the UserWarFile parameter is set to No, you have to make sure that the eG agent install user is added to the WebLogic users group.

WebLogicJarLocation

Specify the location of the WebLogic server's java archive (Jar) file. If the UseWarFile flag is set to No, then the weblogic.jar file specified here is used to connect to the corresponding WebLogic server using the T3 protocol. Note that the T3 protocol-based support is available for WebLogic servers ver.9 and above.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

Active threads

Indicates the total number of active threads in this pool.

Number

A high value for this measure is indicative of a high load on the applications deployed on the WebLogic 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.

Hogging threads

Indicates the number of threads that are currently hogged by a request.

Number

Ideally, the value of this measure should be low. A very high value indicates that a request is using up too many threads. Hogging threads will either be declared as stuck after the configured timeout or will return to the pool before that. The self-tuning mechanism will backfill if necessary.

WebLogic Server automatically detects when a thread in a pool becomes “stuck.” Because a stuck thread cannot complete its current work or accept new work, the server logs a message each time it diagnoses a stuck thread. WebLogic Server diagnoses a thread as stuck if it is continually working (not idle) for a set period of time. You can tune a server’s thread detection behavior by changing the length of time before a thread is diagnosed as stuck, and by changing the frequency with which the server checks for stuck threads. Although you can change the criteria WebLogic Server uses to determine whether a thread is stuck, you cannot change the default behavior of setting the “warning” and “critical” health states when all threads in a particular execute queue become stuck.

Idle threads

Indicates the number of idle threads (i.e., the threads that are ready to process a new job as and when it arrives) in the pool.

Number

A high value is desired for this measure.

Queue length

Indicates the number of pending requests in the priority queue.

Number

This measure comprises of both the internal system requests and requests made by the user.

A low value is desired for this measure. A high value or a sudden increase in this value may indicate a sudden slowdown in responsiveness or a performance bottleneck.

Standby threads

Indicates the number of threads that are currently in the standby pool.

Number

Threads that are not needed to handle the present work load are designated as standby and are added to the standby pool. These threads are activated when more threads are needed.

Throughput

Indicates the number of requests in the priority queue that are completed.

Number

The queue monitors throughput over time and based on history, determines whether to adjust the thread count or not. For example, if historical throughput statistics indicate that a higher thread count increased throughput, the server increases it. Similarly, if statistics indicate that fewer threads did not reduce throughput, the count will be reduced.

Total threads

Indicates the total number of threads in this pool.

 

Number