ZA380/ZA580 Unit 19

Performance monitoring
This unit is about monitoring system performance for WebSphere Application Server.

Unit objectives
After completing this unit, you should be able to:
 Describe performance monitoring and tuning methodology
 Use the Tivoli Performance Viewer to monitor application server resources
 Use the performance servlet to generate performance data
 Configure the Request Metrics tool to generate performance data about the end-to-end request flow
 Use Performance Advisors to generate recommended tuning actions
 Enable the performance collectors from ITCAM for WebSphere Application Server

Topics
In this unit, the following topics are presented:
 Performance tuning and monitoring
 Request metrics
 Performance advisors
 ITCAM for WebSphere Application Server

Performance tuning and monitoring

This topic introduces performance tuning and monitoring terminology, best practices, and performance monitory and tuning
tools that are packaged with WebSphere Application Server V8.

The need for performance monitoring and tuning

The goal of performance monitoring is to collect runtime statistics on your application and its environment to quantify their
performance behavior. It allows you to determine whether your application meets its performance objectives and helps to
identify any performance bottlenecks. It is important to monitor system performance because poor performance can result in
higher support costs, loss of customer confidence, and loss of revenue. Monitoring ensures that applications are running as
expected, and if not, the cause of performance problems can be investigated. WebSphere Application Server can function
well with default settings, but some applications can require further tuning for optimal performance.

Tuning performance best practices

Tuning WebSphere Application Server is a critical part of getting the best performance from your website. But tuning
WebSphere Application Server involves analyzing performance data and determining the optimal server configuration.
This determination requires considerable knowledge about the various components in the application server and their
performance characteristics. The performance advisors encapsulate this knowledge, analyze the performance data, and
provide configuration recommendations to improve the application server performance. Therefore, the performance advisors

1
© Copyright IBM Corporation 2012
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
ZA380/ZA580 Unit 19

provide a starting point to the tuning process for the application server, and help you without requiring that you become an
expert.
Take advantage of performance functions. Obtain performance advice from the advisors. Tune the environment.
Troubleshoot performance problems. For more information, see the list of resources that are displayed on the slide.

Performance terminology
This slide displays a list of terms that are commonly associated with performance. Creating a glossary of performance terms
is essential for good performance monitoring. The glossary is used to ensure that everyone who is involved understands the
meaning of each term, decreasing the chance of inaccurate performance statistics.
Response time measures an individual user’s average wait for a request. Response times include the cumulative time that is
spent in processing the request, time that is spent in transit between systems, and the wait time that is spent in queues.

Tuning parameter hot list

To ensure optimal performance of your applications, some other things to keep in mind are listed on the slide.

Solving a performance problem

The diagram illustrates the process of addressing a performance problem. Tuning your application and runtime environment
involves conducting many iterations of this monitor, tune, and test cycle. This process is often iterative because when one
bottleneck is removed, the performance is now constrained by some other part of the system. For example, replacing slow
hard disks with faster ones might shift the bottleneck to the processor of a system.

Measuring performance and collecting data

To measure performance, begin by choosing a benchmark. A benchmark is a standard set of operations to run. This
benchmark exercises those application functions experiencing performance problems. Complex systems frequently need a
warm-up period to cache objects and optimize code paths. System performance during the warm-up period is much slower
than after the warm-up period. The benchmark must be able to generate work that warms up the system before recording
the measurements that are used for performance analysis. Depending on the system complexity, a warm-up period can
range from a few thousand transactions to longer than 30 minutes. If the performance problem under investigation occurs
when many clients use the system, then the benchmark must also simulate multiple users.
Another key requirement is that the benchmark must be able to produce repeatable results. If the results vary more than a
few percent from one run to another, consider the possibility that the initial state of the system might not be the same for
each run. The measurements are made during the warm-up period or that the system is running additional workloads.
Several tools facilitate benchmark development. The tools range from tools that invoke a URL, to script-based products that
can interact with dynamic data that the application generates. IBM Rational has tools that can generate complex interactions
with the system under test and simulate thousands of users. Producing a useful benchmark requires effort and needs to be
part of the development process. Do not wait until an application goes into production to determine how to measure
performance. The benchmark records throughput and response time results in a form to allow graphing and other analysis
techniques. There are two types of data that can be collected with WebSphere Application Server.
The performance data that WebSphere Application Server Performance Monitoring Infrastructure (PMI) provides helps to
monitor and tune the application server performance. Request metrics are another source of performance data that
WebSphere Application Server provides. Request metrics allow a request to be timed at WebSphere Application Server
component boundaries, enabling a determination of the time that is spent in each major component.

2
© Copyright IBM Corporation 2012
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
ZA380/ZA580 Unit 19

WebSphere performance tools (1 of 3)

WebSphere Application Server provides the following tools, or facilities, to monitor and tune system performance: The Tivoli
Performance Viewer or TPV, request metrics, performance advisors, and the performance servlet, all of which are described
in more detail in this unit.

WebSphere performance tools (2 of 3)

PMI data can be viewed by using tools that are built into the administrative console, or can be viewed in XML form by using
the performance servlet. Request metrics are written to the logs, and can also be viewed by using an ARM agent. IBM Tivoli
Composite Application Manager (ITCAM) for WebSphere was introduced in version 7. ITCAM for WebSphere gives you
some additional monitoring capabilities such as CPU usage per application.

WebSphere performance tools (3 of 3)

This slide displays where the different tools collect the data and where it is displayed. Tivoli Performance Viewer and
Advisors use PMI data to calculate statistics and display them in the administrative console. The performance servlet also
uses PMI data. You install the performance servlet application on at least one server in the cell. A client can then make an
HTTP request for the performance servlet. Performance statistics are return to the client in XML format.
Request metrics collect information about application transactions. This information can be found in the SystemOut.log file or
sent to a client that is ARM enabled.

WebSphere performance tools (3 of 3)

The Performance Monitoring Infrastructure (PMI) uses a client-server architecture.
The server collects performance data from various WebSphere Application Server components. A client retrieves
performance data from one or more servers and processes the data.
In WebSphere Application Server, Version 6 and later, PMI counters are enabled based on a monitoring or instrumentation
level. The levels are None, Basic, Extended, All, and Custom. These levels are specified in the PMI module XML file.
Enabling the module at a level includes all the counters at the level plus counters from all levels below it. For example,
enabling the module at the extended level enables all the counters at that level plus all the basic level counters as well.
The server collects PMI data in memory. This data consists of counters such as servlet response time and data connection
pool usage. The data points are then retrieved by using a web client, a Java client, or a Java Management Extensions (JMX)
client. WebSphere Application Server contains Tivoli Performance Viewer, a Java client which displays and monitors
performance data.

Types of performance data

The types of data that can be collected include system resources such as CPU utilization and statistics for WebSphere pools
and queues. Others types of data include the database connection pool, and customer application data, such as average
servlet response time.

PMI data collection settings

PMI counters are enabled, based on a monitoring or instrumentation level. The levels are None, Basic, Extended, All, and
Custom. These levels are specified in the PMI module XML file. Enabling the module at a level includes all the counters at
the level plus counters from all levels below it. For example, enabling the module at the extended level enables all the
counters at that level, plus all the basic level counters as well.

3
© Copyright IBM Corporation 2012
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
ZA380/ZA580 Unit 19

Each statistic set is a collection of a set of performance counters. If you select none, then no statistics are being collected. If
you select basic, then you are collecting statistics that include Java EE applications, HTTP session, and CPU usage. If you
select extended, then you are collecting the basic statistics plus statistics that include workload management and dynamic
caching. If you select all, then you collect all available statistics. Finally, you can select custom and choose the individual
components that you want to collect statistics.

Enabling PMI by using the administrative console

PMI is enabled per server. To enable PMI, in the console, select Servers > Server Types > WebSphere Application
Servers > server_name.
On the Configuration tab for the server, under Performance, click Performance Monitoring Infrastructure (PMI). Select
the Enable Performance Monitoring Infrastructure (PMI) check box.

Start monitoring
After enabling PMI for the server, in the console, select Monitoring and Tuning > Tivoli performance Viewer >
server_name > Start Monitoring. Then, go back to Monitoring and Tuning > Tivoli performance Viewer > current
activity.

Tivoli Performance Viewer interface (1 of 4)

In the Tivoli Performance Viewer, you can view graphs and reports that display PMI statistics. This portion of the screen
shows the navigation tree in Tivoli Performance Viewer where you can select which components to monitor. In this case, the
JVM runtime module is selected.

Tivoli Performance Viewer interface (2 of 4)

Statistics for the selected modules display in a graph on the right. In this example, statistics for the JVM runtime are shown.
There are buttons to control the data that is being shown. If you do not want to view the data in a graph, you can click View
Table to view the data in a table form, instead. There are also check boxes that you can select to show or hide specific
counters.

Tivoli Performance Viewer interface (3 of 4)

Reset to zero - Sets a new baseline by using the current counter readings at the instant the button is clicked. Future data
points are plotted on the graph relative to their position at the time Reset to Zero is clicked. Data points that are gathered
before the time Reset to Zero option is clicked are not displayed, although they are still held in the Tivoli Performance
Viewer buffer. If Undo Reset to Zero is clicked again, Tivoli Performance Viewer displays all data currently in the buffer from
their original baseline, not from the Reset to Zero point.
View Table/View Graph - To view the data in a table, click View Table on the counter selection table. To toggle back to a
chart, click View Graph.
Show Legend/Hide Legend - To view the legend for a chart, click Show Legend. To hide the legend, click Hide Legend.
Clear Buffer - To clear values from the table or chart, click Clear Buffer beneath the chart or table, which removes all PMI
data.

4
© Copyright IBM Corporation 2012
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
ZA380/ZA580 Unit 19

Tivoli Performance Viewer interface (4 of 4)

This screen is an example of what the table view looks like for the JVM runtime module statistics.

Summary reports
Another option for viewing PMI data is selecting one of the summary reports available. These summary reports collect a
number of statistics for a broader group of related components into a report form.

Example: Servlet summary report

The screen shows an example of the servlet summary report. The servlet summary lists all servlets that are running in the
current application server. Use the servlet summary view to quickly find the most time-intensive servlets and the applications
that use them, and to determine which servlets are called most often.
You can sort the summary table by any of the columns. Some tips include:
 Sort by Avg Response Time to find the slowest servlet or JSP page.
 Sort by Total Requests to find the servlet or JSP used the most.
 Sort by Total Time to find the most costly servlet or JSP.

Performance servlet overview

The performance servlet provides a way to use an HTTP request to query the PMI for an entire WebSphere Application
Server administrative domain. This option can be used to allow users without administrative console access to view
performance data using HTTP. The PerfServlet provides the performance data output as an XML document, as described in
the provided DTD. In the XML structure, the leaves of the structure provide the actual observations of performance data and
the paths to the leaves provide the context.
The PerfServlet in WebSphere Application Server uses the JMX Perf MBean interface to retrieve the PMI data and outputs
an XML document that uses the Java EE Performance Data Framework to describe the statistics. The perfservlet EAR file is
in the WAS_HOME/installableApps directory. You must enable WebSphere security for it to work properly. It is deployed
like any other servlet.

Performance servlet output

This slide shows you the output of a performance servlet request. The snapshot shows the performance statistics about
Snoop servlet.

Request metrics topic

Request metrics are covered in this topic.

5
© Copyright IBM Corporation 2012
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
ZA380/ZA580 Unit 19

Request metrics overview

Request metrics allow you to monitor the transaction flow and analyze the response time of the components that are
involved in runnning it. This analysis can help you target performance problem areas and debug resource constraint
problems.
For example, it can help determine when a transaction spends most of its time in the web server plug-in, the web container,
the Enterprise JavaBeans (EJB) container, or the network database. The response time that is collected for each level
includes the time that is spent at that level and the time that is spent in the lower levels.
For example, if the total response time for the servlet is 130 milliseconds, and it includes 38 milliseconds from the enterprise
beans and Java Database Connectivity, then 92 ms can be attributed to the servlet process. The diagram illustrates where
request metrics are collected in a request flow. An ARM agent does not ship with WebSphere Application Server but third-
party tools can provide an ARM agent.

Enabling request metrics collection

In the administrative console, select Monitoring and Tuning > Request Metrics and select the checkbox to Prepare
Servers for Request metrics collection.
Trace level - Specifies how much trace data to accumulate for a transaction.
The trace level and components to be instrumented work together to control whether a request is instrumented or not. It
includes one of the following values:
 None, No instrumentation.
 Hops - Generates instrumentation information about process boundaries only. When this setting is selected, you see
the data at the application server level, not the level of individual components such as enterprise beans or servlets.
 Performance_debug - Generates the data at Hops level and the first level of the intraprocess servlet and Enterprise
JavaBeans (EJB) call. For example, when an inbound servlet forwards to a servlet and an inbound EJB calls another
EJB. Other intraprocess calls, like naming and service integration bus (SIB), are not enabled at this level.
 Debug - Provides detailed instrumentation data, including response times for all intraprocess calls. Note: Requests
to servlet filters is instrumented only at this level.
 Standard logs: Enables the request metrics logging feature. Select this check box to trigger the generation of
request metrics logs in the SystemOut.log file. Since enabling the request metrics logging feature increases
processor usage, it is suggested to use this feature together with filters so that only selected requests are
instrumented.
 Application Response Measurement (ARM) agent - Enables request metrics to call an underlying Application
Response Measurement (ARM) agent. Before enabling ARM, you need to install an ARM agent and configure it to
the appropriate class path and path, following the instructions of the ARM provider.

Isolating performance for specific types of requests

On the request metrics filter page, you can select the filter type; for example source IP address, and select the check box to
enable filtering. Click the Filter Values link to specify a value for the filter. The request metrics filters are enabled according
to your configuration. For example, if you enabled source IP, only requests whose source IP matches the one specified in
the filter are instrumented.
Filters are checked only for edge transactions. An edge transaction is the transaction that first enters an instrumented
system. For example, if a servlet calls an EJB, the servlet is the edge transaction. Assuming it is not instrumented at the web
server plug-in, and the URI and SOURCE_IP filters is checked for the servlet request.

6
© Copyright IBM Corporation 2012
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
ZA380/ZA580 Unit 19

However, when the request comes to the EJB container, the EJB filter is not checked because it is no longer an edge
transaction. You must regenerate the web server plug-in configuration file after modifying the request metrics configuration.

Example request metric data

Here is an example of the request metrics data that is captured in the SystemOut.log

Performance advisors topic

This topic describes performance advisors.

Performance advisors overview

The advisors provide various advice on the following application server resources:
 Object Request Broker service thread pools
 Web container thread pools
 Connection pool size
 Persisted session size and time
 Data source statement cache size
 Session cache size
 Dynamic cache size
Java virtual machine heap size
 DB2 performance configuration wizard
 Connection use violations
For example, consider the data source statement cache. It optimizes the processing of prepared statements and callable
statements by caching those statements that are not used in an active connection. (Both statements are SQL statements
that essentially run repeatable tasks without the costs of repeated compilation.) If the cache is full, an old entry in the cache
is discarded to make room for the new one.
The best performance is generally obtained when the cache is large enough to hold all of the statements that are used in the
application. The PMI counter, prepared statement cache discards, indicates the number of statements that are discarded
from the cache. The performance advisors check this counter and provide recommendations to minimize the cache discards.
Another example is thread or connection pooling.
The idea behind pooling is to use an existing thread or connection from the pool instead of creating an instance for each
request. Because each thread or connection in the pool uses memory and increases the context-switching cost, the pool
size is an important configuration parameter. A pool that is too large can hurt performance as much as a pool that is too
small. The performance advisors use PMI information about current pool usage, minimum or maximum pool size, and the
application server CPU utilization to recommend efficient values for the pool sizes. The advisors can also issue diagnostic
advice to help in problem determination and health monitoring. For example, if your application requires more memory than
is available, the diagnostic adviser tells you to increase the size of the heap for the application server.

Performance and diagnostics advisors (1 of 5)

There are two performance advisors available: the Performance and Diagnostic Advisor and the performance advisor in
Tivoli Performance Viewer. The slide lists the types of information that each one provides. The Performance and Diagnostic
Advisor runs in the JVM process of the application server therefore; it does not provide expensive advice. In a stand-alone
application server environment, the performance advisor in Tivoli Performance Viewer runs within the application server
JVM.

7
© Copyright IBM Corporation 2012
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
ZA380/ZA580 Unit 19

The performance advisor in Tivoli Performance Viewer (TPV) provides advice to help tune systems for optimal performance
and provide recommendations on inefficient settings by using collected PMI data. Obtain the advice by selecting the
performance advisor in TPV. In a network deployment environment, the performance advisor in TPV runs within the JVM of
the node agent and can provide advice on resources that are more expensive to monitor and analyze. The TPV advisor
requires that you enable performance modules, counters, or both.

Performance and diagnostics advisors (2 of 5)

To obtain advice, you must first enable PMI through the administrative console and restart the server. The Performance and
Diagnostic Advisor enables the appropriate monitoring counter levels for all enabled advice when PMI is enabled. If specific
counters exist that are not wanted, or when disabling the Performance and Diagnostic Advisor, you might want to disable
PMI or the counters that the Performance and Diagnostic Advisor enabled.
If running WebSphere Application Server Network Deployment, you must enable PMI on both the server and the
administrative agent, and restart the server and the administrative agent.
Click Servers > Application servers in the administrative console navigation tree.
Click server_name > Performance and Diagnostic Advisor Configuration.
Under the Configuration tab, specify the number of processors on the server. This setting is critical to ensure accurate
advice for the specific configuration of the system.
Select the Calculation Interval. PMI data is taken over time and averaged to provide advice. The calculation interval
specifies the length of time over which data is taken for this advice. Therefore, details within the advice messages display as
averages over this interval.
Select the Maximum Warning Sequence. The maximum warning sequence refers to the number of consecutive warnings
that are issued before the threshold is updated. For example, if the maximum warning sequence is set to 3, then the advisor
sends only three warnings to indicate that the prepared statement cache is overflowing. After three warnings, a new alert is
issued only if the rate of discards exceeds the new threshold setting.
Specify Minimum CPU for Working System. The minimum central processing unit (CPU) for a working system refers to the
CPU level that indicates an application server is under production load. Or, if you want to tune your application server for
peak production loads that range from 50 - 90% CPU utilization, set this value to 50. If the CPU is below this value, some
diagnostic and performance advice is still issued. For example, regardless of the CPU level if you are discarding prepared
statements at a high rate, you are notified.
Specify CPU Saturated. The CPU saturated level indicates at what level the CPU is considered fully used. The level
determines when concurrency rules no longer increase thread pools or other resources, even if they are fully used.
Click Apply.
Click Save.

Performance and diagnostics advisors (3 of 5)

You can enable and disable advice in the Advice Configuration panel. Some advice applies only to certain configurations
and can be enabled only for those configurations. For example, unbounded Object Request Broker (ORB) service thread
pool advice is only relevant when the ORB service thread pool is unbounded, and can be enabled only when the ORB thread
pool is unbounded. For more information about advice configuration, see the advice configuration settings information.
In this example, advice about Session Cache Size with Overflow Disable is being generated.

8
© Copyright IBM Corporation 2012
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
ZA380/ZA580 Unit 19

Performance and diagnostics advisors (4 of 5)

The Performance and Diagnostic Advisor recommendations are displayed in two locations:
 The WebSphere Application Server SystemOut.log log file.
 The Runtime Messages panel in the administrative console. To view this administrative page, click
Troubleshooting > Runtime Messages > Runtime Warning.
This slide shows the advice as runtime events in the administrative console.

Performance and diagnostics advisors (5 of 5)

When you select a tune message from the runtime events panel, it displays the detailed information. Notice that you get the
message, an explanation, and action that the user can take. The advisor does not make the recommended change and the
administrator must apply the advice. After the advice is applied, save the configuration, and restart the server.

Tivoli performance viewer advisor

The performance advisor in Tivoli Performance Viewer provides advice to help tune systems for optimal performance and
provides recommendations on inefficient settings by using the collected Performance Monitoring Infrastructure (PMI) data.
Obtain advice by clicking Performance Advisor in Tivoli Performance Viewer. The performance advisor in Tivoli
Performance Viewer provides more extensive advice than the Performance and Diagnostic Advisor. For example, Tivoli
Performance Viewer provides advice on setting the dynamic cache size, setting the Java virtual machine (JVM) heap size,
and by using the DB2 Performance Configuration wizard.

Examples of performance advice

Here are some examples of performance advice.
The example is using PMI statistics about the rate of prepared statements that are discarded from the cache, which is high.
The setting implies that some connections are creating new prepared statements instead of retrieving ones from the cache
which is not a good practice as the application server is creating and removing prepared statements. Also, the PMI statistics
are showing that there is enough available memory in the heap. The advice is to increase the size of the prepared statement
cache.

Viewing performance advice

In the TPV, click the link that says Advisor. If the server generated some advice, it is shown in this table. Look for the
messages that say “Tune”. In this example, some of the messages are warnings and others are configuration
recommendations. From the list of advice, you can select the message link to get more detailed information. The messages
can be sorted by severity.

Performance advice detail

Click the message link that you want to investigate and the details about the message are displayed. Notice that you get the
full message, severity, description of the problem, the action the administrator must take, and some detail about the status of
the current setting.

9
© Copyright IBM Corporation 2012
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
ZA380/ZA580 Unit 19

Performance advisor best practices

Here are some things to consider when using the performance advisors. CPU utilization must rise above 50% before advice
is generated. Typically when running your production level load, you push the CPU usage to 80–100% before turning on one
of the performance advisors. If the load changes on the system peaks under test, contradictory advice is generated, which is
because the collected PMI data shows a different type of environment, causing the advice to shift. To avoid the problem,
always run the advisors while simulating the load WebSphere experiences during deployment (peak load). If the minimum
and maximum pool size values are the same, the performance advisor rules are much more likely to give contradictory
advice when the load fluctuates. The amount of CPU usage determines the amount of system activity. The advisors do not
consider disk activity, network activity, memory usage, or other factors to get a more realistic view of system load.
Performance advisors from different application servers can give contradictory advice on the same node resources. Different
information is because the application servers take into account how they are individually employing the resource. In this
situation, if the advice from the different advisors varies greatly, consider the generated advice and make the needed
changes. However, if all advisors are giving the same recommendations, then you must seriously consider the suggested
changes.
If the performance advisor suggests setting a pool size to X, you might set the minimum value to X/2 and the maximum
value to X. If the performance advisor suggests setting the prepared statement cache value to a certain setting, check the
amount of memory that is available before setting. The advisors do not take into account the amount of actual physical
memory available on the system before making suggestions.

ITCAM for WebSphere Application Server

This topic describes ITCAM for WebSphere and how to configure and use it.

IBM Tivoli Composite Application Manager (ITCAM)

IBM Tivoli Composite Application Manager is a suite of products that are used to monitor and manage applications. ITCAM
enables users to view the health of applications and servers. ITCAM has several data collectors for different servers.

ITCAM for WebSphere Application Server

ITCAM for WebSphere Application Server is an optional component that you can install during the installation of WebSphere
Application Server. ITCAM for WebSphere Application Server monitors the performance of WebSphere Application Server
applications and provides real-time status information about the health of applications. You can view this data in the Tivoli
Performance Viewer console in WebSphere Application Server.
The ITCAM for WebSphere Application Server component is composed of a Data Collector. After you install this component,
configure the Data Collector to a WebSphere Application Server instance. The Data Collector runs within the same JVM as
the application server and captures information about the running applications. This Data Collector Configuration tool adds a
Performance Monitoring Infrastructure (PMI) module in the application server. The data that ITCAM for WebSphere
Application Server provides augments the data the application server provides through the existing PMI statistics.

ITCAM for WebSphere Application Server

Tto begin receiving performance information from ITCAM, complete the following steps:
1. In the administrative console navigation pane, click Monitoring and Tuning > Performance Monitoring
Infrastructure (PMI).
2. Select the application_server instance that you want to monitor, in this case it is server1.

10
© Copyright IBM Corporation 2012
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
ZA380/ZA580 Unit 19

3. Under Additional Properties, click ITCAM for WebSphere Application Server. After you make this selection, you
will see that Enable IBM Tivoli Composite Application Manager for WebSphere Application Server is selected.
4. Click the Runtime tab.
5. Click Start Monitoring. The system starts monitoring the ITCAM for WebSphere Application Server module, and the
Tivoli Performance Viewer sends the signal to ITCAM by using a Java Management Extensions (JMX) call. ITCAM
for WebSphere Application Server registers all performance modules from the PMI registry and starts monitoring
performance.

ITCAM metrics in Tivoli Performance Viewer

To view ITCAM monitoring information in Tivoli Performance Viewer, you must enable the counters.
1. In the navigation pane, click Monitoring and Tuning > Performance Viewer > Current Activity.
2. Expand Performance Modules and click ITCAM Application Performance.
3. To refresh the view, click Tivoli Performance Viewer and select the application_server instance for which you want
to view performance data.
.
ITCAM application metrics in TPV
This slide displays some of the metrics that you can receive from ITCAM. The metrics are for the ShoppingServlet.

Unit summary
After completing this unit, you should now be able to:
 Describe performance monitoring and tuning methodology
 Use the Tivoli Performance Viewer to monitor application server resources
 Use the performance servlet to generate performance data
 Configure the Request Metrics tool to generate performance data about the end-to-end request flow
 Use Performance Advisors to generate recommended tuning actions
 Enable the performance collectors from ITCAM for WebSphere Application Server

11
© Copyright IBM Corporation 2012
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.