IBM WebSphere Developer Technical Journal: <comment lines> from Ruth Willenborg

Selecting WebSphere performance tools

Today, there are many performance testing options, so there is no single answer to the question of which tool (or tools) you need. Since performance is important at each stage in the development lifecycle, we will take a look at the tool requirements and options for each development stage.

Ruth Willenborg, Senior Technical Staff Member, EMC

Author photoRuth Willenborg is a Senior Technical Staff Member in IBM's WebSphere Technology Institute. Ruth is currently working on WebSphere Cloud computing and virtual appliance initiatives, and is the technical evangelist for the new IBM WebSphere CloudBurst Appliance. Prior to her work on virtualization and appliance initiatives, Ruth was the manager of the WebSphere Performance team responsible for WebSphere Application Server performance analysis, performance benchmarking and performance tool development. Ruth has over 20 years of experience in software development at IBM. She is co-author of Performance Analysis for Java Web Sites (Addison-Wesley, 2002).



13 October 2004

Selecting WebSphere performance tools

Five years ago, in the early days of WebSphere®, I was often asked what tools to use for debugging performance problems. The answer was a quick one. In those days, we were lucky to get a basic profiler to run, and as far as looking at performance under load, a JVM thread dump or print statements in the application was the only recourse. Today, the answer is very different; there are so many options, and every Java™ magazine includes lots of ads for tools promising to solve your performance woes. In addition, IBM's recent acquisitions of Candle® and Cyanea, both offering WebSphere performance tools, along with existing capabilities from Tivoli®, Rational®, and WebSphere, likely have you asking the questions: Where do I start, what tools do I need, and what's the difference between all these products?

Of course, there is no single answer to which tool (or tools) you need, so let's discuss the different types of tools and the primary problems each tool solves. Since performance is important at each stage in the development lifecycle, we will look at tool requirements for each stage, starting with development.

I always recommend choosing a good code profiler and using it during application development. A code profiler helps identify and optimize code hot spots, and really helps in understanding object usage and potential memory leaks. Entering the which-code-profiler-is-best debate is a little like the age-old which-is-the-best-editor debate, so I am not going to pick one here. The good news is there are now several excellent profilers for use with WebSphere applications. Since IBM's acquisition of Rational, several members of my performance team use Rational PurifyPlus™ on a daily basis. In addition to using a code profiler, J2EE Code Validation Preview for WebSphere Studio (a new technology preview) can be run against your application to identify common performance and correctness problems in your implementation.

While I always encourage profiling, there are some performance problems that are not typically caught during the development profiling stage. For example, common scalability problems, including synchronization issues and database contention, do not surface until load tests. Anticipate these types of problems and invest in a good load test environment, as close to the production environment as possible. Web site load testing tools are quite mature, with many excellent options available. Developing load test scripts is a significant investment, as is the associated training, so make sure to do a thorough evaluation of your requirements prior to selecting a load driving tool, as the cost to switch tools later can be high.

Once you move into a load test environment, you will need views of your application beyond what traditional profilers provide. Most profilers introduce extremely high performance overhead, and so are not designed to effectively showcase performance data in a highly concurrent environment. Therefore, analyzing performance at this stage requires different tools. There are a couple of "free" tools available for WebSphere which are sufficient for the performance testing needs of many load test environments. One is the Tivoli Performance Viewer, packaged with WebSphere Application Server, which graphically displays WebSphere performance data (PMI), including information on WebSphere resources such as pools and caches, J2EE application metrics such as response time and number of requests, and basic system metrics. Use this data to determine likely bottleneck locations, tune the system, and to understand particularly slow and frequently used servlets or EJB components for additional analysis and profiling. For the top ten metrics to start with, please refer to my Meet the Experts article.

If the problem remains a mystery after analyzing the PMI data, a set of thread dumps of the JVM often pinpoints synchronized methods and other common problems. WebSphere Thread Analyzer is available for free download to quickly display your thread dump in a more visually appealing manner.

Tivoli Performance Viewer and thread dumps may be sufficient for what you need but, if not, there are now extremely powerful tools available from both IBM and other vendors to really see inside the application under load conditions. These tools, which I think of as run time profilers provide detailed views of where time is spent in your application and often include capabilities to view performance down to specific SQL calls, and also pinpoint the cause of memory leaks. IBM WebSphere Studio Application Monitor (aka Cyanea/One], as well as partner tools such as Wily Introscope and Quest PerformaSure, provide these types of capabilities.

While good load testing prevents many production performance problems, production environments often present unique challenges -- especially as changes are introduced to many different interacting applications and backend systems. Having a good production monitoring strategy remains a necessity. A Web site monitoring strategy requires the ability to view performance from the end-user perspective, understanding the health of all the systems within the Web site (including WebSphere Application Server as well as database servers, directory servers, and other componentry), and understanding the health of the specific applications. At a minimum, I recommend at least basic monitoring of each of these three categories, including report and alerting capabilities. Products such as Tivoli Monitoring for Transaction Performance provide the capability to monitor your site from the end-user perspective, and, in combination with WebSphere's request metrics instrumentation, also provides views into application performance. For looking at the health of all your servers, consider the capabilities of Tivoli (Candle) OMEGAMON® or similar vendor solutions. When additional granularity is desired, products such as WebSphere Studio Application Monitor, which was discussed above for load testing, are also useful in production environments.

Over time, I expect to see significant integration efforts across Tivoli Monitoring for Transaction Performance, Candle OMEGAMON, and WebSphere Studio Application Monitor to provide even stronger WebSphere production monitoring solutions. In addition, we can look forward to integration with the Rational development and testing solutions to provide more capabilities across the life cycle. Until then, select the specific products for your performance needs, and look forward to getting even better capabilities in the future.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=23253
ArticleTitle=IBM WebSphere Developer Technical Journal: <comment lines> from Ruth Willenborg
publish-date=10132004