Performance Monitoring Infrastructure (PMI) provides server-side
monitoring and a client-side API to retrieve performance data. PMI maintains
statistical data within the entire WebSphere Application Server domain, including
multiple nodes and servers. Each node can contain one or more WebSphere Application
Servers. Each server organizes PMI data into modules and submodules.

The
Tivoli Performance Viewer, formerly the Resource Analyzer, organizes performance
data in a centralized hierarchy of the following objects:
- Node. A node represents a physical machine in the WebSphere Application
Server administrative domain.
- Server. A server is a functional unit that provides services to
clients over a network. No performance data is collected for the server itself.
- Module. A module represents one
of the resource categories for which collected data is reported to 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 enterprise beans, JDBC connection pools, J2C connection
pool, Java Virtual Machine (JVM) run time (including Java Virtual Machine
Profiler Interface (JVMPI)), servlet session manager, thread pools, transaction
manager, Web applications, Object Request Broker (ORB), Workload Management
(WLM), Web Services Gateway (WSGW), and dynamic cache.
- Submodule. A submodule represents a fine granularity of a resource
category under the module. For example, ORB thread pool is a submodule of
the thread pool category. Submodules can contain other submodules.
- Counter. A counter is a 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.
The Tivoli Performance
Viewer allows users to view and manipulate the data for counters. A particular
counter type can appear in several modules. For example, both the servlet
and enterprise bean modules have a response time counter. In addition, a counter
type can have multiple instances within a module. For example, in the figure
above, both the Enterprise beans module and Bean1 have an Avg Method RT counter.
Counters
are enabled at the module level and can be enabled or disabled for elements
within the module. For example, in the figure, if the enterprise beans module
is enabled, its Avg Method RT counter is enabled by default. However, you
can then disable the Avg Method RT counter even when the rest of the module
counters are enabled. You can also, if desired, disable the Avg Method RT
counter for Bean1, but the aggregate response time reported for the whole
module no longer includes Bean1 data.
Each counter has a specified monitoring
level: none, low, medium, high or maximum. 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 application server. 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, enterprise bean, methods in a bean
- Data counters for this category report 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 Tivoli Performance Viewer
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
- Data counters for this category contain 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.
- Java 2 Connector (J2C) connection pool
- Data counters for this category contain usage information about the Java
2 Platform Enterprise Edition (J2EE) Connector architecture that enables enterprise
beans to connect and interact with procedural back-end systems, such as Customer
Information Control System (CICS), and Information Management System (IMS).
Examples include the number of managed connections or physical connections
and the total number of connections or connection handles.
- Java Virtual Machine API (JVM)
- Data counters for this category contain memory used by a process as reported
by Java Virtual Machine (JVM) run time. Examples are the total memory available
and the amount of free memory for the JVM. JVM run time also includes data
from the Java Machine Profiler Interface (JVMPI). This data provides detailed
information about the JVM running the application server.
- Servlet session manager
- Data counters for this category contain 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
- Data counters for this category contain information about the thread pools
for Object Request Broker (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)
- Data counters for this category contain 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 applications, 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.
- Object Request Broker (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.
- Alarm manager
- Data counters for this category contain information for the Alarm Manager.
- Object pool
- Data counters for this category contain information for Object Pools.
- Scheduler
- Data counters for this category contain information for the Scheduler
service.
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*: Java Database Connectivity (JDBC) connection pool PMI data
- J2CResourceAdapter*: Java 2 Connectivity (J2C) connection pool PMI data
- JVM: Java virtual machine PMI data
- MessageDrivenBean*: specific EJB PMI data (BeanModule)
- ORB: Object Request Broker PMI data
- Server: PMI data in the whole server, you must 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 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=mynode,server=myserver,*";
Set
the mytype, mynode, 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 Developing your own monitoring applications .