Monitoring WebSphere performance

Learn about the resources available in WebSphere to monitor performance and how to use them to avoid bottlenecks.

This Content Component encountered an error

To adequately understand the performance of a hardware or software system, you need to understand two things: what performance data can be captured for analysis and what tools are out there to help you analyze the data.

All machines and systems depend upon resources that affect their performance. When resources become low, performance is reduced. Therefore the keys to ensuring your WebSphere environment is running at peak performance are:

  1. Understanding what resources your WebSphere environment relies upon
  2. Understanding how WebSphere applications use those resources
  3. Knowing what tools to use to monitor and record the usage of resources
  4. Determining how best to approach performance bottlenecks

In terms of WebSphere, you will want to monitor memory, database connections, threads, transaction times and servlet response times. Resources that are available to monitor are:

  • Enterprise Beans Resource: This tracks the number of active EJBs and their response times. You use this resource to identify poor application response times due to excessive use of EJBs in an application.

  • Connection Pools Resource: This tracks the average size of the connection pool and the average number of threads waiting for a connection. It is useful for identifying poor application response times due to limited database resources.

  • JVM Resource: Each application server runs in its own JVM instance. The JVM Resource helps to identify memory available to the JVM and memory usage by the application server.

  • Session Manager Resource: This resource tracks the number of sessions (temporary object storage areas that servlets and JSPs use to maintain application state) and the average session life span. Since sessions eat up memory, careless use of them can reduce performance.

  • Thread Pools Resource: This tracks the thread that the application server uses to process requests for EBJs and from the Web server. It can help you decide how to best allocate threads to the application server.

  • Transaction Manager Resource: This also tracks EJB transactions. It looks at the average concurrent transactions, duration of transactions and the number that are committed, rolled back and timed out. This resource can help you identify poor performance due to excessive use of EJB entity beans.

  • The Web Application Resource: Use this to track the load of Web applications and servlets. Because users interact with Web applications via servlets, their perception of an application's performance is directly related to the servlet's response time. Using this resource, you can identify heavily used applications and distribute them over server clusters, as well as slow application entry points and servlet code issues.

Fortunately, performance monitoring and analysis capabilities are built right into WebSphere, in the form of the Performance Monitoring Infrastructure (PMI). You don't have to worry about starting and stopping PMI because it's a core piece of WebSphere that's always running. However, when you want to monitor WebSphere performance, you must enable monitoring for the specific applications server that you want to monitor. PMI interfaces with WebSphere administration utilities to enable administrators to control the amount and level of performance data collected. You can access the PMI administrative interface by using the Administrative Console.

PMI captures and makes available performance data from various run time resources, such as JVM and Thread Pools and application components, such as servlets and Enterprise Java Beans (EJBs). It captures such things as the average number of threads waiting for a connection to a database, the amount of free memory available to the JVM, or the average amount of time it takes for an HTTP session to perform a request.

This data must then be analyzed by one of two tools that IBM provides for just such a purpose: The Tivoli Performance Viewer (formerly Resource Analyzer) and the Performance Monitoring Servlet.

  • Tivoli Performance Viewer: Formerly called the Resource Analyzer, this is Java application records and reports data captured by the PMI. It can help you determine what resources are being used, and how best to tune them for better performance; it can also record and play back performance "events" for the benefit of developers. The Performance Viewer also includes the Performance Advisor, which provides a technical assessment, based on the performance data, of what sorts of configuration changes the administrator ought to make to thread pools, connection pools, the prepared statement cache, session cache and heap size.

  • The Performance Monitoring Servlet: This is a Web-based alternative to the Tivoli Performance Viewer. It returns performance data in an XML format that can be useful for automated processing of performance information. It can be somewhat cumbersome for monitoring resources manually though. The performance monitoring servlet is a J2EE application that is distributed with WebSphere. However, it is not installed by default, so you'll have to install if you want to use it. You can find the application in the WebSphereAppServerinstallableApps folder; it's called PerfServletApp.ear. One of the key benefits of the servlet is that it can be used to view performance data from anywhere via a Web browser. However, on the downside, it doesn't provide a graphical interface for navigating data items or creating charts. Nor can it store information in a log file for later analysis or playback -– as the Tivoli performance Viewer can.

There are also plenty of other tools available to help you monitor and tweak WebSphere for peak performance. IBM Tivoli provides an array of application, database and network monitoring products. In addition, there are also third-party products available; IBM lists these here.

But by starting with the PMI and related tools, you can get a good start on understanding performance issues in your WebSphere applications.

You now know what resources WebSphere has, how WebSphere applications use those resources and how to monitor those resources. Next comes the challenging part: Determining what to do when resources become very low and cause a performance bottleneck. We'll address this topic in our August article, "Tuning WebSphere for optimum performance."

About the authors:
Tony Higham is the chief solutions officer at FatWire Software and an expert on Lotus, WebSphere and Java technologies. He can be reached at tony.higham@FatWire.com.

Sue Hildreth is a contributing writer and editor based in Waltham, Mass. She can be reached at Sue.Hildreth@comcast.net.

Do you have comments on this tip? Let us know.

Please let others know how useful it is via the rating scale below. Do you have a useful Notes/Domino tip or code to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.

This was first published in July 2004

Dig deeper on IBM WebSphere

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchWinIT

Search400

  • iSeries tutorials

    Search400.com's tutorials provide in-depth information on the iSeries. Our iSeries tutorials address areas you need to know about...

  • V6R1 upgrade planning checklist

    When upgrading to V6R1, make sure your software will be supported, your programs will function and the correct PTFs have been ...

  • Connecting multiple iSeries systems through DDM

    Working with databases over multiple iSeries systems can be simple when remotely connecting logical partitions with distributed ...

SearchEnterpriseLinux

SearchVirtualDataCentre.co.UK

Close