Monitoring overall system health is fundamentally important to understanding the health of every system involved with your system. This includes web servers, application servers, databases, back-end systems, and any other systems critical to running your web site.
Metric | Meaning |
---|---|
Average response time | Include statistics, for example, servlet or enterprise beans response time. Response time statistics indicate how much time is spent in various parts of WebSphere Application Server and might quickly indicate where the problem is (for example, the servlet or the enterprise beans). |
Number of requests (transactions) | Enables you to look at how much traffic is processed by WebSphere Application Server, helping you to determine the capacity that you have to manage. As the number of transactions increase, the response time of your system might be increasing, showing the need for more system resources or the need to retune your system to handle increased traffic. |
Number of live HTTP sessions | The number of live HTTP sessions reflects the concurrent usage of your site. The more concurrent live sessions, the more memory is required. As the number of live sessions increase, you might adjust the session time-out values or the Java virtual machine (JVM) heap available. |
![]() ![]() |
Interpret the web server thread pools, the web container thread pools, and the Object Request Broker (ORB) thread pools, and the data source or connection pool size together. These thread pools might constrain performance due to their size. The thread pools setting can be too small or too large, therefore causing performance problems. Setting the thread pools too large impacts the amount of memory that is needed on a system or might cause too much work to flow downstream if downstream resources cannot handle a high influx of work. Setting thread pools too small might also cause bottlenecks if the downstream resource can handle an increase in workload. |
![]() ![]() |
|
Database and connection pool size | |
Java virtual memory (JVM) | Use the JVM metric to understand the JVM heap dynamics, including the frequency of garbage collection. This data can assist in setting the optimal heap size. In addition, use the metric to identify potential memory leaks. |
CPU | You must observe these system resources to ensure that you have enough system resources, for example, CPU, I/O, and paging, to handle the workload capacity. |
I/O | |
System paging |
WebSphere Application Server
for z/OS® relies on WLM services to collect some
of the accounting and performance data.
Resource
Measurement Facility (RMF™) and RMF-written System Management
Facility (SMF) records present performance and accounting information
to the WebSphere Application Server. In addition,
the WebSphere Application Server for z/OS has
SMF records that collect additional domain-specific information
Turn off the SMF records or RMF data
using the administrative console and the SMFPRMxx parmlib member if
you do not need the information. Use the SMFPRMxx parmlib member to
control the detail of the WebSphere Application Server
for z/OS SMF records. If you need SMF information,
review the SMF records to ensure you are collecting only the record
types and details that you need.
Setting up your
workload manager goals and filtering criteria is beyond the scope
of this section. You can classify work into service classes based
on user ID and server name. Classify the control regions as reasonably
high-performing system tasks
To monitor several of these statistics, WebSphere Application Server provides the Performance Monitoring Infrastructure to obtain the data, and provides the Tivoli® Performance Viewer in the administrative console to view this data.
To
monitor several of these statistics, WebSphere Application
Server provides the Performance Monitoring Infrastructure to obtain
the data, and provides the Tivoli Performance Viewer and
the optional IBM Tivoli Composite Application
Manager for WebSphere Application Server in the administrative
console to view this data.