InfoCenter Home >
6: Administer applications >
6.6: Tools and resources quick reference >
6.6.0: About user assistance >
6.6.0.12: About the WebSphere Resource Analyzer

6.6.0.12: About the WebSphere Resource Analyzer

This section introduces the WebSphere Resource Analyzer and contains the following topics:


Introduction to the WebSphere Resource Analyzer

The WebSphere Resource Analyzer is a Graphical User Interface (GUI) performance monitor for IBM WebSphere Application Server Version 4.0, Advanced Edition for Multiplatforms. You can use the Resource Analyzer to retrieve performance data from the application servers. Data is collected continuously by the application servers and retrieved as needed from within the Analyzer. You can regulate the impact incurred from data collection by using the Resource Analyzer or the WebSphere Advanced Administrative Console. (See Understanding instrumentation levels for data collection.) The Resource Analyzer's graphical interface provides controls that enable you to choose the particular resources and counters to include in a view.

The Resource Analyzer provides access to a wide range of performance data for two kinds of resources:

  • Application resources (for example, enterprise beans and servlets)

  • WebSphere run-time resources (for example, Java Virtual Machine (JVM) memory, application server thread pools, and database connection pools)

Performance data includes simple counters, statistical data (such as the response time for each method invocation of an enterprise bean), and load data (such as the average size of a database connection pool during a specified time interval). This data is reported for individual resources and aggregated for multiple resources.

Depending on which aspects of performance are being measured, you can use the Resource Analyzer to accomplish the following tasks:

  • View data in real time or view historical data from log files.

  • View data in chart form, allowing comparisons of one or more statistical values for a given resource on the same chart. In addition, different units of measurement can be scaled to enable meaningful graphic displays.

  • Record current performance data in a log and replay performance data from previous sessions.

  • Compare data for a single resource to an aggregate (group) of resources on a single node.

Data collection and reporting incurs a cost--it can affect the performance of your distributed applications. Although performance data is automatically collected at all times, it is not reported by default. Instead, you must explicitly enable the reporting of the data that is collected for your monitored system. The WebSphere Advanced Administrative Console provides a dialog box for specifying which data is to be collected for which resources. If data is not being collected for a particular resource, the data point is not registered and therefore cannot be displayed in the Resource Analyzer. Even when data reporting is enabled, the types of data displayed depend on user-defined instrumentation levels. See Understanding instrumentation levels for data collection.

To ensure the efficient operation of WebSphere Application Server, data collection for the machine on which the application server resides needs to be maintained with a minimum of overhead. To accomplish this requirement, no significant calculations are made on the server side. Instead, the Resource Analyzer uses the Performance Monitoring Infrastructure (PMI) client to hold and manipulate raw data that is reported by the server.


Resource categories monitored by the Resource Analyzer

The Analyzer collects and reports performance data for the following resource categories (modules):

  • Enterprise beans. Data for this category reports 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. It reports information for enterprise bean methods, which are the remote interfaces used by an enterprise bean. Examples include the number of times a method was called and the average response time for the method. It also reports information on the size and usage of a cache of bean objects (enterprise bean object pools). Examples include the number of calls attempting to retrieve an object from a pool and the number of times an object was found available in the pool.

  • Database connection pools. Data for this category reports usage information about connection pools for a database. Examples are the average size of the connection pool (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 was in use.

  • J2C Connectors. Data for this category reports usage information about the J2EE (Java 2 Enterprise Edition) 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 are the number of managed connections (physical connections) and the total number of connections (connection handles).

  • JVM run time. Data for this category reports memory used by a process as reported by the JVM. Examples are the total memory available and the amount of free memory for the JVM.

    JVMPI run time. In addition, the Resource Analyzer makes use of a Java Virtual Machine Profiler Interface (JVMPI) to enable a more comprehensive performance analysis. This profiling tool enables the collection of information about the Java Virtual Machine (JVM) that runs the application server. See Enabling JVMPI data reporting.

  • Servlet session manager. Data for this category reports usage information for HTTP sessions. Examples include the total number of sessions being accessed, the average amount of time it takes for a session to perform a request, and the average number of concurrently active HTTP sessions.

  • Thread pools. Data for this category reports information about the pool of Object Request Broker (ORB) threads that an application server uses to process remote methods and the Web container pools that are used to process HTTP requests coming into the application server. 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.

  • Transaction manager. Data for this category reports transaction information for the container. Examples include the average number of active transactions, the average duration of transactions, and the average number of methods per transaction.

  • Web applications. Data for this category reports 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.

How performance data is organized

The Resource Analyzer organizes performance data in a centralized hierarchy of the following objects:

  • Node. A node represents a physical machine in the WebSphere administrative domain. No performance data is collected for the node itself.

  • 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 data is collected to be reported to the Resource Analyzer: enterprise beans, database connection pools, J2C Connectors, JVM run time, JVMPI run time, servlet session manager, thread pools, transaction manager, Web applications.

  • Method. A method is software that implements a specified operation within a Java class. For the Resource Analyzer, information is collected on instance methods.

  • Servlet. A servlet is a Java program that extends some functionality of the Web server. It generates dynamic data in response to client requests. For the Resource Analyzer, information is collected on the servlets in Web application.

  • 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 counters track activities that can have an impact on system performance. Counters measure some aspect of a running system, for example, the number of active enterprise beans, the time spent in responding to a servlet request, or the number of kilobytes of available memory.

Modules can have instances, which are single instantiations of an object within a class. Counters can be assigned to any number of modules and instances or to no group at all. For example, the diagram in Figure 1 shows that the counter Avg Method Rt (average method response time) belongs to the Enterprise Beans module, and in addition, the method associated with the Container2.Bean1 instance also uses the Avg Method Rt counter. The diagram in Figure 1 shows a hierarchy of data collections that are organized for reporting to the Resource Analyzer.

Figure 1. Example hierarchy of collections of performance data reported for Resource Analyzer

Example hierarchy of collections of performance data reported for Resource Analyzer

Each instance can have counters activated or deactivated for each module (resource category), for example, the enterprise beans category. In addition, each module has its own a set of counters. The modules and instances can include or exclude any or all of the counters that are available, based on the object type and the instrumentation level. (See Understanding instrumentation levels for data collection.)

Instances uniquely identify objects within them to modules by using a concatenation of the name of the instance and the name of the object. For example, Figure 1 shows instances named Container1 and Container2. The instances contain objects named Bean1. Each instance.object is uniquely identified by its full name: Container1.Bean1, Container2.Bean1, and Container2.Bean2.

The object Bean1 belongs in both instances, Container1 and Container2. Container1.Bean1 and Container2.Bean1 are distinct instances with different activities occurring within each. The information that is reported for the same object in two instances will differ according to the difference in activity occurring in each instance. For example, Container1.Bean1 and Container2.Bean1 both have the Gets Found counter enabled. The data reported by the Gets Found counter in Container1.Bean1 reflects only the activity occurring in Container1. Similarly, the Gets Found counter in Container2.Bean1 only reports activity in Container2.

The information that is reported on Container1.Bean1 and Container2.Bean1 also differs according to which counters are enabled within each instance. For example, the Num Destroys counter is enabled in Container1.Bean1, but not in Container2.Bean1. Therefore, no report is made to Resource Analyzer on the number of bean objects that were destroyed in Container2.Bean1.

If the instrumentation level for the enterprise bean category is set to high, then the counter Avg Method Rt (average method response time) is available to be enabled (because its impact cost rating is medium) in the Enterprise Beans module. When the instrumentation level is set at the module level, the same instrumentation level is automatically invoked for all instances occurring within the module. Because aggregate data is reported at the module level, the average response time on all methods for each instance is reported.

However, it is possible to select any single instance and reset the instrumentation level for that specific instance. So, for example, if the value for the instrumentation level for Container2.Bean2 is reset to low, then no report from Container2.Bean2 is included in the aggregate value reported by the Avg Method Rt counter at the module level because the counter's medium impact cost rating is excluded when the instance's instrumentation level is set to low. Detailed information is provided in Rating the impact of performance monitoring.


How performance data is accessed and reported

The Resource Analyzer uses the Performance Manager Infrastructure (PMI) to manipulate the raw data that is collected about the application server. As an application runs, raw data is saved into the application server's memory. The PMI client takes the raw data and completes the complex calculations that change the raw data into meaningful performance statistics. The PMI client removes the overhead of performing these calculations at the application server. This enables a minimum performance impact for data collection on the application server and ensures the optimal efficiency of the running application. Figure 2 shows how the PMI client reports performance data to analytical tools.

Figure 2. How the PMI client gathers and reports performance data

How the PMI client gathers and reports performance data

Figure 2 shows the three types of analytical tools that can access performance data reported by the PMI client:

  • A Web client can use the Hypertext Transfer Protocol (HTTP) to activate a servlet that is designed to gather performance data on the application server by using the PMI client. The PMI client retrieves the raw data from the application server or servers and completes the required calculations for display by the servlet.

  • A Java client can access the PMI client directly to get meaningful performance data. The PMI client uses Remote Messaging Interface/Internet Inter-ORB Protocol (RMI/IIOP) to exchange data with the administrative server.

  • The Resource Analyzer uses the calculations reported by the PMI client to construct graphic and tabular displays representing application performance.

The application server records the sum, the count, and the sum of the squares (for standard deviation calculations). It also maintains calculations that provide a time-weighted dimension to the statistical data: the time-weighted sum (which is updated each time the counter is changed), the time when the counter was created, the time when the counter was last updated, and the current value of the counter.

With this data, the Resource Analyzer can be used to do the following types of analysis:

  • Monitor real-time performance, such as response times for servlet requests or enterprise bean methods

  • Detect trends by analyzing logs of data over time

  • Determine the efficiency of a configuration of resources (such as the amount of allocated memory, the size of database connection pools, and the size of a cache for enterprise bean objects)

  • Gauge the load on application servers and the average wait time for clients
Go to previous article: Execute commands using EJB CommandTarget support Go to next article: Rating the impact of performance monitoring

 

 
Go to previous article: Execute commands using EJB CommandTarget support Go to next article: Rating the impact of performance monitoring