Performance data

PMI provides server-side monitoring and a client applications for retrieving WAS domain performance data. TPV organizes PMI data into the following categories:

Node Represents a physical machine in the WAS administrative domain.
Server Functional unit that provides services to clients over a network. No performance data is collected for the server itself.
Module Main category in the performance viewer. Each module has a configuration file in XML format. This file determines organization and lists a unique identifier for each performance data in the module. Modules include...

Submodule Subset of a resource category. For example, ORB thread pool is a submodule of the thread pool category. Submodules can contain other submodules.
Counter Data type used to hold performance information for analysis. Each resource category (module) has an associated set of counters. The data points within a module are queried and distinguished by the MBean ObjectNames or PerfDescriptors. Examples of counters include the number of active enterprise beans, the time spent responding to a servlet request and the number of kilobytes of available memory.

Counters are enabled at the module level and can be enabled or disabled for elements within the module.

Each counter has a specified monitoring level:

If the module is set to lower monitoring level than required by a particular counter, that counter is not enabled. Thus, if Bean1 has a medium monitoring level, Gets Found and Num Destroys are enabled because they require a low monitoring level. However, Avg Method RT is not enabled because it requires a high monitoring level.

Data collection can affect performance of the appserver. The impact depends on the number of counters enabled, the type of counters enabled and the monitoring level set for the counters.

The following PMI modules are available to provide statistical data...

Enterprise bean module Load values, response times, and life cycle activities for enterprise beans. Examples include the average number of active beans and the number of times bean data is loaded or written to the database. Information is provided for enterprise bean methods and the remote interfaces used by an enterprise bean. Examples include the number of times a method is called and the average response time for the method. In addition, the TPV reports information on the size and use of a bean objects cache or enterprise bean object pool. Examples include the number of calls attempting to retrieve an object from a pool and the number of times an object is found available in the pool.

JDBC connection pools Usage information about connection pools for a database. Examples include the average size of the connection pool or number of connections, the average number of threads waiting for a connection, the average wait time in milliseconds for a connection, and the average time the connection is in use.

J2C connection pool Usage information about the J2EE Connector architecture that enables enterprise beans to connect and interact with procedural back-end systems, such as CICS, and IMS. Examples include the number of managed connections or physical connections and the total number of connections or connection handles.

JVM API Memory used by a process as reported by JVM run time. Also includes data from the JVMPI.

Servlet session manager Usage information for HTTP sessions. Examples include the total number of accessed sessions, the average amount of time it takes for a session to perform a request, and the average number of concurrently active HTTP sessions.

Thread pool Information about the thread pools for ORB threads and the Web container pools used to process HTTP requests. Examples include the number of threads created and destroyed, the maximum number of pooled threads allowed, and the average number of active threads in the pool.

Java Transaction API (JTA) Performance information for the transaction manager. Examples include the average number of active transactions, the average duration of transactions, and the average number of methods per transaction.

web application (.war)s, servlet Data counters for this category contain information for the selected server. Examples include the number of loaded servlets, the average response time for completed requests, and the number of requests for the servlet.

ORB Data counters for this category contain information for the ORB. Examples include the object reference lookup time, the total number of requests, and the processing time for each interceptor.

Web Services Gateway (WSGW) Data counters for this category contain information for WSGW. Examples include the number of synchronous and asynchronous requests and responses.

System data Data counters for this category contain information for a machine (node). Examples include the CPU utilization and memory usage. Note that this category is available at node level, which means it is only available at NodeAgent in the multiple servers version.

Workload Management (WLM) Data counters for this category contain information for workload management. Examples include the number of requests, the number of updates and average response time.

Dynamic cache Data counters for this category contain information for the dynamic cache service. Examples include in-memory cache size, the number of invalidations, and the number of hits and misses.

Web services Data counters for this category contain information for the Web services. Examples include the number of loaded Web services, the number of requests delivered and processed, the request response time, and the average size of requests.

You can access PMI data through the getStatsObject and the getStatsArray method in the PerfMBean. You need to pass the MBean ObjectName(s) to the PerfMBean.

Use the following MBean types to get PMI data in the related categories...

DynaCache dynamic cache PMI data
EJBModule * Enterprise Java Bean (EJB) module PMI data (BeanModule)
EntityBean * specific EJB PMI data (BeanModule)
JDBCProvider * JDBC connection pool PMI data
J2CResourceAdapter * J2C connection pool PMI data
JVM JVM PMI data
MessageDrivenBean * specific EJB PMI data (BeanModule)
ORB Object Request Broker PMI data
Server PMI data in the whole server, pass recursive=true to PerfMBean
SessionManager * HTTP Sessions PMI data
StatefulSessionBean * specific EJB PMI data (BeanModule)
StatelessSessionBean * specific EJB PMI data (BeanModule)
SystemMetrics system level PMI data
ThreadPool * thread pool PMI data
TransactionService JTA Transaction PMI data
WebModule * web application (.war) PMI data
Servlet * servlet PMI data
WLMAppServer Workload Management PMI data
WebServicesService Web services PMI data
WSGW * Web services gateway PMI data

To use the AdminClient API to query the MBean ObjectName for each MBean type. You can either query all the MBeans and then match the MBean type or use the query String for the type only: String query = "WebSphere:type=mytype,node=node,server=myserver,*";

Set the mytype, node, and myserver values accordingly. You get a Set value when you call the AdminClient class to query MBean ObjectNames. This response means that you can get multiple ObjectNames.

In the previous example, the MBean types with a star (*) mean that there can be multiple ObjectNames in a server for the same MBean type. In this case, the ObjectNames can be identified by both type and name (but mbeanIdentifier is the real UID for MBeans). However, the MBean names are not predefined. They are decided at run time based on the applications and resources. When you get multiple ObjectNames, you can construct an array of ObjectNames that you are interested in. Then you can pass the ObjectNames to PerfMBean to get PMI data. You have the recursive and non-recursive options. The recursive option returns Stats and sub-stats objects in a tree structure while the non-recursive option returns a Stats object for that MBean only. More programming information can be found in "Develop your own monitoring applications".

 

Performance data classification

PMI provides server-side data collection and client-side API to retrieve performance data. Performance data has two components: static and dynamic.

The static component consists of a name, ID and other descriptive attributes to identify the data. The dynamic component contains information that changes over time, such as the current value of a counter and the time stamp associated with that value.

The PMI data can be one of the following statistical types defined in the JSR-077 specification...

RangeStatistic data contains current value, as well as lowWaterMark and highWaterMark.

In general, CountStatistic data require a low monitoring level and TimeStatistic data require a medium monitoring level. RangeStatistic and BoundedRangeStatistic require a high monitoring level.

There are a few counters that are exceptions to this rule. The average method response time, the total method calls, and active methods counters require a high monitoring level. The Java Virtual Machine Profiler Interface (JVMPI) counters, SerializableSessObjSize, and data tracked for each individual method method(level data) require a maximum monitoring level.

In previous versions, PMI data was classified with the following types:

These PMI data types continue to be supported through the PMI API. Statistical data types are supported through both the PMI API and Java Management Extension (JMX) API.

The TimeStatistic type keeps tracking many counter samples and then returns the total, count and average of the samples. An example of this is an average method response time. Given the nature of this statistic type, it is also used to track non-time related counters, like average read and write size. You can always call getUnit method on the data configuration information to learn the unit for the counter.

In order to reduce the monitoring overhead, numeric and stat data are not synchronized. Since these data track the total and average, the extra accuracy is generally not worth the performance cost. Load data is very sensitive, therefore, load counters are always synchronized. In addition, when the monitoring level of a module is set to max, all numeric data are also synchronized to guarantee accurate values.

 

Performance data refresh behavior

New performance data can become available in either of the following situations...

In both cases, if the resource in question is already polled by the Tivoli Performance Viewer or the parent of the resource is being polled, the system is automatically refreshed. If more counters are added for a group that the performance viewer is already polling, the performance viewer automatically adds the counters to the table or chart views. If the parent of the newly added resource is polled, the new resource is detected automatically and added to the Resource Selection tree. You can refresh the Resource Selection tree, or parts of it, by selecting the appropriate node and clicking the Refresh icon, or by right-clicking a resource and choosing Refresh.

When an appserver runs, the performance viewer tree automatically updates the server local structure, including its containers and enterprise beans, to reflect changes on the server. However, if a stopped server starts after the performance viewer starts, a manual refresh operation is required so that the server structure accurately reflects in the Resource Selection tree.

Clicking refresh with server selected under the viewer icon causes TPV to query the server for new PMI and product configuration information. Clicking refresh with server selected under the advisor icon causes TPV to refresh the advice provided, but will not refresh PMI or product configuration information.

 

Performance data log file

An example of the performance data log file format is below.

 

Location

By default, this file is written to 

$WAS_INSTALL/logs/ra_mmdd_hhmm.xml

where mmdd=month and date, and hhmm=hour and minute

 

Usage Notes

This read-write data file is created by Tivoli Performance Viewer and provides data collected by the performance viewer. The log file is not updated, but remains available for you to replay the collected data. The performance data log file does not have an effect on the WebSphere environment.

 

Example

<?xml version="1.0"?>
<RALog version="5.0">
<RAGroupSnapshot time="1019743202343" numberGroups="1">
        <CpdCollection name="root/peace/Default Server/jvmRuntimeModule" level="7">
            <CpdData name="root/peace/Default 
            Server/jvmRuntimeModule/jvmRuntimeModule.total/Memory" id="1">
                <CpdLong value="39385600" time="1.019743203334E12"/>
            </CpdData>
            <CpdData name="root/peace/Default 
         Server/jvmRuntimeModule/jvmRuntimeModule.freeMemory" id="2">
                <CpdLong value="4815656" time="1.019743203334E12"/>
            </CpdData>
            <CpdData name="root/peace/Default 
        Server/jvmRuntimeModule/jvmRuntimeModule.usedMemory" id="3">
                <CpdLong value="34569944" time="1.019743203334E12"/>
            </CpdData>
        </CpdCollection>
    </RAGroupSnapshot>
</RALog>

 

See Also

  1. Storing data to a log file
  2. Enterprise Java Bean counters
  3. Gateway counters
  4. Web servivices counters
  5. Dynamic cache counters
  6. JDBC connection pool counters
  7. Enterprise Java Bean counters
  8. Webapplication counters
  9. Workload Management counters
  10. System counters
  11. Java Virtual Machine counters
  12. ORB counters
  13. Servlet session counters
  14. Transaction counters
  15. Thread pool counters
  16. Webapplication counters
  17. Workload Management counters
  18. System counters
  19. Java Virtual Machine counters
  20. ORB counters
  21. Servlet session counters
  22. Transaction counters
  23. Thread pool counters
  24. EJB method Invocation Queuing Refreshing data
    Using the Performance Advisor in Tivoli Performance Viewer
    Monitoring performance