WebSphere Thread Pools Test

To optimize performance and at the same time to support concurrent accesses from users, the application server uses thread pools. It is critical to monitor a WebSphere server’s thread pools on an ongoing basis. This test does just that.

Target of the test : A WebSphere application server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for each thread pool that exists on a WebSphere application server

Configurable parameters for the test
Parameters	Description
Test Period	How often should the test be executed .
Host	The IP address of the WebSphere application server
Port	The port number of the WebSphere application server
WebServerPort	The port number through which the WebSphere applications can be accessed. (For IBMHTTPServer this information can be found in the httpd.conf file located in $<INSTALLDIR>/conf directory.)
SSL	Indicate whether the SSL (Secured Socket Layer) is to be used to connect to the WebSphere server.
ServerHostName	Specify the node name of the server instance being monitored. To know the node name, do the following: Login to the WebSphere Administrative Console. Expand the Servers node in the tree structure in the left pane of the console, and click on the Application Servers link within. A list of application server instances and their corresponding node names will then appear in the right pane of the console. From this list, you can figure out the node name that corresponds to the application server instance being monitored, and specify that name against the ServerHostName parameter.
NDManager	The NDManager parameter is applicable only under the following circumstances: If the WebSphere server being monitored belongs to a cluster, or, If the WebSphere server being monitored is one of many instances of the server running on the same host In the case of situation (a), in the NDManager text box, provide the host name of the node manager that manages the application servers in the cluster. To know the name of the Node Manager, do the following: Login to the Administrative Console of the node manager using the URL http://<IPoftheWebSphereAppServer'sNodeManager>:<Adminport>/admin/. Using the tree-structure in the left pane of the Administrative Console that appears, drill down to the Deployment Manager node within System Administration. Select the Configuration tab that appears in the right pane, and scroll down to the End Points link in the Additional Properties section. Once you locate the End Points link, click on it, and in the page that appears, click on the SOAP_CONNECTOR_ADDRESS link. In the subsequent page, a fully qualified domain name will be displayed against Host. This is the name that should be specified as the host name of the node manager in the NDManager text box. In the case of situation (b), enter the ServerHostName itself as the NDManager. If both conditions (a) and (b) do not apply, then specify none here.
ConnectorPort	The ConnectorPort parameter is applicable only under the following circumstances: If the WebSphere server being monitored belongs to a cluster, or, If the WebSphere server being monitored is one of many instances of the server running on the same host In case of situation (a), the ConnectorPort parameter will take the port number using which the node manager communicates with the WebSphere servers in the cluster. The connector port can be a SOAP port or an RMI port. To know the port number, do the following: From the Node manager's host, open the <WEBSPHERE_INSTALL_DIR>\DeploymentManager\properties\wsadmin.properties file. Two entries that read as follows will be present in the wsadmin.properties file: com.ibm.ws.scripting.port=<port_number> #com.ibm.ws.scripting.port=<port_number> Both the entries will have port numbers against them. However, the uncommented entry (the entry without the #) is the one that denotes an active port. Therefore, specify the corresponding port number as the ConnectorPort. In case of situation (b), do the following to know the ConnectorPort: Login to the WebSphere Administrative Console. Expand the Servers node in the tree-structure in the left pane of the console, and click on the Application Servers link. A list of application server instances will then appear in the right pane. Click on the server instance being monitored. Doing so invokes the Configuration of the chosen server instance appears. Scroll down the Configuration to view the End Points link. Once you locate the End Points link, click on it. In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link. The Port displayed in that page should be used as the ConnectorPort in situation (b). If both (a) and (b) do not apply, specify none against ConnectorPort.
User	If security has been enabled for the WebSphere server being monitored, then provide a valid User name to login to the WebSphere server. If the WebSphere server does not require any authentication, then the User text box should contain the default value 'none'.
Password	If security has been enabled for the WebSphere server being monitored, then provide the Password that corresponds to the specified User name. If the WebSphere server does not require any authentication, then leave the Password text box with its default setting.
Confirm Password	If security has been enabled, confirm the specified Password by retyping it in the Confirm Password text box. If the WebSphere server does not require any authentication, then leave the Confirm Password text box with its default setting.
EncryptPass	By default, this flag is set to Yes, indicating that the Password of the WebSphere server is encrypted by default. To disable password encryption, select the No option.
ServerName	Specify the name of the WebSphere server instance to be monitored. To know the instances of a WebSphere server currently available, first, connect to the WebSphere Administrative console using the URL: http://<IP address of the WebSphere server:Port number of the WebSphere server>\admin. Then, login to the administrative console and expand the Servers node in the left pane of the console. Next, click on the Application Servers sub-node under the Servers node. A list of server instance Names and their corresponding Node values will then be displayed in the right pane. One of the displayed server instances can be specified as the value of the ServerName parameter.
Timeout	In the Timeout text box, specify the maximum duration (in seconds) for which the test will wait for a response from the application server. The default Timeout period is 60 seconds.

Measurements made by the test
Measurement	Description	Measurement Unit	Interpretation
Threads created	This measure indicates the rate at which the threads are being created in the pool.	Threads/Sec	A sudden increase in the value of this measure directly relates to an increase in the activity happening in this application.
Threads destroyed	This measure indicates the rate at which the threads are being destroyed in the pool.	Threads/Sec	A decrease in the value of this measure indicates that the threads are being active for a long period of time, which might indicate anomalies within the application.
Active threads	Indicates the average number of active threads in the pool.	Number	A high value for this measure is indicative of a high load on this application and combined with the creation and destroy rates might give insights of the application pattern. 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.
Pool size	Indicates the average number of threads in the pool.	Number	If the pool size is high and the number of active threads is low, it signifies that the threads are not being destroyed immediately after use.
Percent maxed	This indicates the average percent of time the number of threads in the pool reached or exceeded the configured maximum number.	Percent	A high value for this measure indicates that the number of threads in the pool needs to be increased for effective operation of this application. Alternatively, you may also consider changing the maximum number of threads that a pool can contain However, exercise caution when altering the maximum thread count, as a very high thread count can cause the app to slowdown from excessive memory usage. Likewise, if the maximum thread count is set too low, it will cause requests to block or timeout. You can use this measure to see how often you are reaching the maximum thread count in a pool. This can be used to tune other properties – such as the amount of time before an idle thread is destroyed and the frequency of when new threads are created.