A Complete Guide to WebSphere Application Server Performance Monitoring

The WebSphere Application Server (WAS) is a popular product from IBM's WebSphere family, used to host applications developed in Java. This product is utilized in many large-scale enterprise services and even in smaller setups. Therefore, ensuring its proper functioning within a service infrastructure is of high importance, and monitoring its health is crucial. 

Within this application server, there is a module called the Performance Monitoring Infrastructure (PMI) which is responsible for collecting performance metrics from various modules. By enabling this module, comprehensive information about the overall health of WebSphere can be obtained. IBM's documentation suggests monitoring specific metrics to ensure the overall health of the WebSphere Application Server (abbreviated as WAS), which are discussed below:

Average Response Time:

Monitoring the average response time involves keeping track of the response times of Servlets and Enterprise Beans. This metric indicates the average time spent in WAS for each of the mentioned cases. By using this parameter and comparing it to its normal value, one can gain insights into the conditions and potential slowdowns of WAS in responding to requests in web and EJB applications.

Request or Transaction Statistics:

These metrics provide comprehensive information about the amount of incoming traffic or the volume of requests to WAS. An increase in these statistics might also impact the average response time, guiding us to increase allocated resources such as the Heap memory in the Java Virtual Machine (JVM).

HTTP Live Session Statistics:

The number of live sessions indicates the level of simultaneous usage of the site. An increase in the number of concurrent sessions requires more memory. Additionally, an increase in this parameter necessitates adjusting session timeout parameters and the Heap size in the JVM.

Thread Pool:

In WAS, various thread pools are designed to handle concurrent requests. The Web Container for managing web requests, Object Request Broker (ORB), TCPChannel.DCS, etc., are examples of the thread pools in use. Configuring the size of the thread pool is crucial. Setting these pools too small or too large can cause performance issues in services. If the size of these pools is set without considering the flow capacity of the subsequent layer (such as the database), it may cause issues in the layer following WAS. Additionally, selecting a large size may require more memory. Conversely, choosing a small size for the pool may create a bottleneck in the service cycle. Therefore, the pool size should be selected based on the volume of requests and the load capacity of the subsequent layers. These configurations cannot be made without knowing the current size of the threads in the pool, and continuous monitoring of pool usage is essential.

Database Connections or Connection Pools:

Connection pools are responsible for managing connections to databases. Proper sizing of these pools, similar to thread pools, depends on the volume of requests and the capacity of the database to handle these requests. Therefore, the connection pools in WAS, known as data sources, need to be monitored. Besides the size of the pool, it is also crucial to monitor the average JDBC response time and the average time the application uses the connection pool. Continuous monitoring of these metrics is essential.

Java Virtual Machine (JVM):

The core of running Java applications in WAS is the Java Virtual Machine, which has important metrics such as JVM CPU usage and Heap memory usage. These metrics must be monitored regularly.

The modules and performance metrics introduced, along with many other WAS performance metrics, are currently monitorable by the comprehensive Moein monitoring software through a standard interface