150 IBM Enterprise Workload Manager
5.7 Reporting
In this section we want to discuss monitoring performance data using the EWLM Control
Center. We concentrate on reports related to our example policy which we previously
discussed. We want to focus on how to use the reports and monitors to find a performance
problem or bottleneck within our application topology. This is not the only value of the
monitors; for a general discussion on reporting functionality refer to 4.4, “Monitor” on
page 104.
We include in our discussion on performance data the following reports:
? First-level analysis
? Topology view
? Details view
EWLM collects and aggregates performance statistics so that you can compare a high-level
goal to the actual performance at all times. The EWLM Control Center provides a
user-friendly way of viewing this information. EWLM captures relevant performance statistics
on each OS instance within a management domain. It then reports an aggregated view of the
real-time state of the domain to the EWLM domain manager. In the EWLM Control Center
you can view detailed statistics of the actual results that were achieved, as opposed to the
desired results. You can capture performance statistics in a tabular form for offline analysis or
for integration into other performance reporting tools.
The available monitoring and reporting functions are useful to determine whether or not there
is a performance problem for a service class. They also provide a view of the logical tiers and
the application environment and help to determine if applications or servers are experiencing
any problems. The statistics include detailed resource usage and delay information, as well
as correlation to specific operating system processes that support each middleware
application.
Make sure you have the Preference setting set to a reasonable value, for example one
minute, for monitoring your service class goal achievement. A good starting point then is the
overview of the assigned performance goals and the actual achievement as shown in
Figure 5-17. For this you need to log in to the EWLM Control Center as a user with the
monitor role like our user ewlmmon. Select Service classes from the monitor task list to view
the performance based on the goals defined in the service policy. There are sorting and
filtering options to customize the view. The values to look at are the performance index (PI),
the importance, and the goal you have set, as well as the actual performance which is
achieved.
SC_Plants_login Medium Percentile Response Time 90% in 200 msec.
SC_Plants_default Medium Average Response Time 100 msec.
SC_Plants_shopping Medium Percentile Response Time 80% in 200 msec.
SC_Trade3_general N/A Discretionary N/A
SC_Plants_general N/A Discretionary N/A
SC_InternetExplorer Medium Velocity Fast
SC_Calc_Batch Medium Velocity Slowest
Service class name Importance Goal type Goal definition
Chapter 5. The ITSO EWLM scenario 151
Figure 5-17 Service class report to identify performance problems
If you click on the PI column header, the service classes are sorted by PI. This will help you
focus on the rows having a PI greater the 1.00
First-level analysis
To verify if the service classes are meeting their goals you can look at the performance index
in this view. Alternatively, you can go to the Exceptions monitor. For this you need to select
Exceptions from the monitor option to get a view as shown in Figure 5-18 on page 151. If
there are no entries in this section all service classes are meeting the business response time
goals you have set.
Figure 5-18 Exceptions report to identify performance problems
We have service class SC_Trade3_shopping listed in this exception section because it has a
performance index greater than one, which means the business goal has been missed. Either
we have set an unrealistic goal or we need to do some further investigation to find out what
caused the bad performance numbers.
For this we select the service class SC_Trade3_shopping and choose Service class details
from the action bar. We press the Go button and are able to view further details on failed,
152 IBM Enterprise Workload Manager
successfully completed, and total number of transactions. This is shown in Figure 5-19. The
Statistics section shows that all transactions are completed successfully, but that only 75% of
the total number is achieving the target response time of 10.00 seconds, while the desired
goal was that 90% of the total transactions be completed within 10.00 seconds. By scrolling
down, we could see a graphical display of the historical response time. Since it does not show
any indication of a problem, we did not include it here.
Figure 5-19 Viewing service class details to identify the performance problem
All transactions seem to be processed successfully, which means we need to look at some
other performance problem indicators.
Topology view
We select service class SC_Trade3_shopping again from the option Exceptions, select
Application topology from the action bar, and click Go. We expect to see the workflow
going from the HTTP plug-in running on server ewlm1 to the Web Server tier running on
servers ewlm2 and ewlm3 and then go to the Database Server ewlm4. This is shown in
Figure 5-20.
Chapter 5. The ITSO EWLM scenario 153
Figure 5-20 Application topology for service class SC_Trade3_shopping
The next step after verifying that your application topology is correct is to look at the table
view to find the application or the server experiencing problems. This view is shown in
Figure 5-21. For each node, that is for each application, server, or instance, the tableview
shows total response time, total active time, the system on which the instance is running, the
number of completed, failed, and abended transactions, and some additional performance
data.
Figure 5-21 Table view for service class SC_Trade3_shopping
There is a lot of data in this tableview that can indicate the performance of the transactions
and diagnose potential problems. First we check the longest active time, which in this
example is on the WebSphere cluster (ewlm2Network). We know that WebSphere
Application Server runs on servers ewlm2 and ewlm3. If the longest active time was showing
high values for our database server we would need to log on there and check if some
processes or applications take up a large amount of server resources.
An indication of a performance problem is a higher active time for one node relative to the
other nodes within the hop. Another indication of a problem is if the successful transaction
count in the table view shows a much lower value for one node than for the others. The failed
transaction count is worth looking at to see if one node has a much higher count relative to
the others or relative to what you expect. Some of these fields, such as transactions counts,
quiesce time, page %, delay time, and so forth, are omitted from the figure because of
formatting but you can see them by scrolling right on the panel.
Managed server details view
We have identified that our WebSphere cluster servers have a relatively high longest active
time value. We can log on to those two servers and check if they have a performance problem
because other applications have a high CPU utilization. Alternatively, we can look at a
Table view Ico n
154 IBM Enterprise Workload Manager
managed server details view. We select Managed servers from the Monitor option, select
ewlm2, for example, and select Managed Server Details from the action bar. After pressing
Go we can examine the Managed Servers details view as shown in Figure 5-22.
Figure 5-22 Details report of WebSphere server ewlm2
This detailed view is available for each server. It provides you with information on the amount
of processors and real memory, the application environment instances, and the average
processor utilization. If this number has a high value, it is a good indication that this may
cause the transactions to fail to complete within the desired response time. In our example
the processor utilization is on average at 41%, which is reasonable. We still log on to the
system to monitor the system more closely and to verify that there are no other applications
using up a large amount of resources.
Another number to look at is the processor delay, which you can see when you scroll down
the view shown in Figure 5-22. A high processor delay could also indicate a reason for your
performance problem.
There are many more details reports and monitors available for performance administrators to
look at. We introduced you to these in 4.4, “Monitor” on page 104, but for finding performance
problems the steps indicated here are a good place to start. This should be sufficient to
narrow down the source of the problem. As described in this section you need to start with an
overall service class view. You can then look further into the operating system instances and
application processes supporting the service class. This allows you to understand where
potential problems exist and to identify the additional support personnel that you may need to
contact to resolve the problem.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.