J2EE

IMPLEMENTING ACOMPREHENSIVE J2EE MONITORING

AND DIAGNOSTIC SOLUTION

Introduction……………………………………………………………………………2

Keys to Successful J2EE Applications ……………………………………………3

Application Delivery ……………………………………………………………3

Application Management ………………………………………………………3

The Unique Challenge of Monitoring J2EE Applications in Production …3

The Complexity of J2EE-based Web Applications …………………………4

The Distribution Nature of J2EE Infrastructure………………………………4

Traditional Systems Management Approaches are Incomplete …………5

Requirements for Effective J2EE Monitoring ……………………………………5

Focusing on the End User and the Entire Business Process………………5

Taking a Business-Centric Approach …………………………………………5

Managing User-Centric SLAs …………………………………………………5

Using a Top-down Analytical Approach ………………………………………6

Collecting Comprehensive Monitoring Information …………………………6

Correlating End-User Experience with Application and System Activity…6

Looking for Typical J2EE Pitfalls ………………………………………………6

Limitations of Current J2EE Application Management Solutions ……………7

Mercury Business Availability Center: A Comprehensive PerformanceManagement Solution for J2EE ……………………………………………………8

Business-Centric IT Management ……………………………………………8

Effective J2EE Application Management: The Mercury Difference ………9

360-Degree Real-Time Monitoring …………………………………………10

Triage Diagnostics ……………………………………………………………11

Deep Diagnostics — Solving the Toughest J2EE PerformanceProblems…………………………………………………………………………11

Mercury Lifecycle Probe: Maximizing Visibility at MinimalOverhead ………………………………………………………………………12

Support for Clustered Environments ………………………………………13

Summary ……………………………………………………………………………13

TABLE OF CONTENTS

INTRODUCTION

J2EE (Java 2 Platform, Enterprise Edition) is the leading standard for

web applications development. J2EE is a Java platform designed to

meet the computing needs of large enterprises. It was designed to

simplify application development in a thin-client multi-tiered

environment, decreasing the need for programming and programmer

training by creating standardized, reusable modular components and

by automatically handling many aspects of programming.

Various vendors, such as IBM, BEA, Sun, and Oracle, have implemented

the J2EE standard and currently market it to enterprises through J2EE

application servers used by leading enterprises to develop their Internet

and intranet applications. The J2EE framework is rapidly growing and

gaining popularity. In a few short years, it has become the preferred

platform for building web-centric, business-critical applications. In fact,

for many Fortune 2000 companies, the J2EE-based application server

has become the heart of their web applications infrastructure.

J2EE

Keys to Successful J2EE Applications

The incentives for deploying and

maintaining high-performance web

applications are greater than ever

before. Once the decision to develop

web-based applications using the J2EE

standard has been made, you will want

to use the best-in-class software and

services to optimize the quality,

performance, and availability of your

J2EE-based application across the

entire application lifecycle. Your

application lifecycle should proceed

along the critical stages of IT

governance, application delivery, and

application management (see Figure 1).

Application Delivery

Testing your application will help you measure application readiness and maximize the quality of your

pre-deployed applications to meet business and end-user requirements. Functional, load, performance,

and scalability testing are all necessary to identify and isolate problems during the various stages of

application development.

The business-critical deployment stage begins when you release applications and systems into

production. Production tuning will help you measure performance readiness and maximize the

efficiency of your applications. An important by-product of production tuning is the establishment of

performance baselines. These baselines will be instrumental in assessing end-user experience with

online transactions and defining service-level agreements (SLAs).

Application Management

After the application has been deployed, organizations must continually verify that the application is

available to all end users and that its performance stays within acceptable limits. The only way to

maintain consistent, high-level performance is through application performance and availability

monitoring — and only a monitoring solution that focuses on end-user experience and employs a

top-down approach will give you a comprehensive, thorough view of your system’s performance

from beginning to end.

The Unique Challenge of Monitoring J2EE Applications in Production

E-business applications are the life-force of your organization. You depend on them to control your

supply chain, inventory, and resources. More importantly, you rely on them to help you manage

relationships with vendors, suppliers, partners, and, of course, customers. Some companies spend

millions of dollars building cutting-edge web applications, but still lose customers. Why? They lack the

WWW.MERCURY.COM 3

OBJECTIVES

BUSINESSAVAILABILITY

SYSTEMPERFORMANCE

APPLICATION READINESS

PLAN DEVELOP TEST DEPLOY OPERATE

IT GOVERNANCE

DEVELOPMENT

Figure 1: The opportunity to optimize.

J2EE

tools to monitor and improve the efficiency and performance of their websites after they are up and

running. Proper monitoring is key to ensuring the performance and scalability of your J2EE applications,

but the J2EE environment presents its own set of monitoring challenges.

The Complexity of J2EE-based Web Applications

Finding a flexible performance management solution that will cover both the internals of the J2EE

environment as well as the supporting infrastructure can be a challenge. The supporting infrastructure

of J2EE-based web applications has a complex multi-tier architectural style composed of client

machines, load balancers, firewalls, web servers,application servers, security servers, transaction

servers, database servers, and network links between these components. Meanwhile, the J2EE

application server likewise has an inherent internal complexity with its “n-tiered,” component-based

architecture (see Figure 2). The application server receives HTTP requests from clients through a web

server, processes them using various J2EE components (e.g., servlets, JSPs, EJBs, and helper classes)

and external entities (e.g., databases and legacy systems) and gives HTTP responses back. When we

also consider that in many J2EE deployment environments there would be two or more applications

servers (and consequently JVMs) run on servers with many processors, it is easy to see why effectively

monitoring J2EE-based web applications is a daunting task.

The Distributed Nature of J2EE Infrastructure

Ideally, the components of a J2EE-based web application should reside in one location, providing you

with the access and control instrumental to their smooth operation. More often than not, different

components are hosted in separate and remote sites, under the supervision of external parties.

Furthermore, due to the nature of the Internet, which is “always open for business” and poses minimal

to no geographical boundaries on users, J2EE applications must be built and managed in a way that will

provide this crucial 24x7 service to every user working from any location in today’s Internet global

village. Website monitors and operators must also keep pace with continually changing infrastructure.

WWW.MERCURY.COM 4

APPLET CONTAINER

APPLICATION CLIENT CONTAINER

WEB CONTAINER EJB CONTAINER

J2SE J2SE

APPLICATION CLIENT

JMS JNDI RMI-IIOP

JDBC

JMS JNDIRMI-IIOP JDBCJTA

JAVAMAIL

JAF

JMS JNDIRMI-IIOP JDBCJTA

JAVAMAIL

JAF

EJBJSP

DATABASE

APPLET

HTTPSSL

SERVLET

Figure 2: J2EE/web application architecture.

J2EE

Traditional Systems Management Approaches are Incomplete

Traditional monitoring and management approaches, such as the enterprise system management (ESM)

approach, have limited success in monitoring J2EE environments since they assume one-to-one

relationships between hardware and software, client and server, and back-end and end user, which do

not reflect the reality of a J2EE-based web infrastructure. On the contrary, the performance of J2EE

applications depends more on the Java Virtual Machine (JVM) and its countless tuning parameters than

on the physical hardware and operating system. Furthermore, multiple J2EE applications may be

integrated with each other, with legacy applications, with web services, or even with all of the above,

making the middleware tier a web of interdependencies.

Requirements for Effective J2EE Monitoring

Once you decide that a J2EE application management solution is vital to your e-business applications,

the question remains: Which solution will yield the highest return on investment (ROI) for your

enterprise? Let us begin by establishing the requirements for an optimal J2EE performance

management solution.

Focusing on the End User and the Entire Business Process

The end-user customer is a business’ most important asset. A web application’s end-user experience

can and should be measured and reported 24 hours a day, seven days a week, whether or not there are

“real” users performing these transactions. How else will a solution verify that all transactions will be

complete and satisfactory for the end user? How else will you be automatically notified when a

performance problem that affects an end user arises?

Taking a Business-Centric Approach

A business-centric approach to managing your application ensures that you will be able to identify and

resolve performance and availability issues before they impact your business and your bottom line.

Such an approach would mean your IT systems, infrastructure, and business processes are aligned to

deliver business results. The optimal performance management solution should enable you to manage

the critical business processes and business transactions delivered by your J2EE application.

Managing User-Centric SLAs

A J2EE performance management solution must enable enterprises and service providers to manage

service levels from a user-centric perspective — providing valuable insight into business health and IT

service levels. It must also provide SLA-compliance reporting for complex business applications in

distributed environments. Rather than monitoring service levels of the individual silo components inside

the infrastructure, organizations should define, measure, and track performance service levels based on

the end-user experience.

WWW.MERCURY.COM 5

J2EE

Using a Top-down Analytical Approach

The first step in monitoring application performance and availability is obtaining a system-wide view of

your application’s health. A top-down display is the optimal way of gaining a comprehensive view of

your J2EE system, allowing you to readily see which applications are functioning properly and which are

“in trouble” and require additional attention. Yet a top-down view alone is not enough for

troubleshooting; the next step is “drilling down” through the application screens in order to link

performance problems with their root causes at the level of granular metrics.

Collecting Comprehensive Monitoring Information

As mentioned, the J2EE-based web infrastructure has a complex architecture. Performance and

availability data should be collected not only from the application server, but also from all the other

systems and components involved in responding to a user request or business process. These

components include databases, security systems, proxy servers, transaction servers, and load

balancers. The challenge, of course, is to collect enough data to satisfy the requirements for high-level,

top-down presentations of information as well as for conducting a detailed analysis of a problem — all

in a way that will have the least overhead possible on the operational level.

Correlating End-User Experience with Application and System Activity

The performance and availability metrics measured from J2EE-based applications and systems have to

be correlated with the end-user experience — correlating, for example, the number of JDBC calls

measured from the application server with a specific business transaction. Once a correlation has been

made, your IT staff can rapidly pinpoint the root cause of a performance and availability issue and move

toward a quick resolution of the problem. Additionally, correlations help prioritize alerts and fault-

recovery efforts around end-user experiences.

Looking for Typical J2EE Pitfalls

Developing applications in Java on the J2EE platform brings its own unique set of performance,

availability, and scalability issues. When monitoring J2EE applications, you want your solution to be

responsive to common J2EE shortcomings, including:

• Poor code, design, and architecture, such as memory leaks, insufficient DB communication,

exorbitant number of remote calls, stateful objects which limit reuse, and unreleased JDBC

connections.

• Poor parameter configuration (e.g., DB queuing and deadlock issues, incorrect pool sizes, incorrect

number of execution threads, too small or too big JVM memory size).

• Poor capacity planning, either by underestimating the number of concurrent users and resources or

overestimating required capacity, which results in wasted money.

• Poor clustering, which can result in improper load balancing, additional performance overhead due to

session persistence, and elimination of high availability if a session always works with the same node

(i.e., due to “sticky” sessions).

WWW.MERCURY.COM 6

J2EE

Limitations of Current J2EE Application Management Solutions

The current generation of J2EE-based applications requires a solution that is proactive as well as

reactive, top-down as well as bottom-up — a solution that will provide clear visibility into the

performance and availability of the entire application infrastructure both from business-centric and IT

perspectives.

While there are several solutions on the market for J2EE application management, most of them

employ a bottom-up IT-centric approach, monitoring the J2EE silo only. These solutions collect

performance metrics from the J2EE application server alone and fail to give operators as well as

business users a holistic view of availability and performance, offering instead a piecemeal depiction of

application performance from the component level. For effective management of J2EE-based

applications, operators and lines of business must understand performance from the end-user

perspective and analyze data accordingly so that changes are realized in the final and most crucial

product of your application efforts — the business transaction.

To summarize, let’s review what is lacking in the traditional “bottom-up, IT-centric” silo approach to

performance monitoring:

• Taking a business-centric approach: The current IT-centric approach doesn’t see the business

impact of J2EE performance issues. It is essential to adopt a business-centric approach to managing

your J2EE applications that enables you to always keep your finger on the pulse of the business.

• Managing user-centric SLAs: The current silo monitoring approach lacks the capabilities to define,

track, and manage service levels that meet business objectives. Without this, maximizing ROI and

profitability by delivering more consistent, predictable performance levels becomes impossible.

• Focus on entire business process from an end-user perspective: The current approach to

monitoring installs agents solely on the application server, while your “real” end users are dispersed

across the globe and must traverse a variety of components (i.e., ISPs, firewalls, networks) in order to

reach the application server. Consequently, data collected by silo solutions measures performance in

a limited space and fails to actually verify whether or not end users are receiving correct content in a

timely and consistent manner.

• A top-down approach: Bottom-up approaches provide information without a meaningful context. For

example, a certain SQL statement took 500 milliseconds to execute. A top-down approach tells you

that 20 percent of users could not complete a purchase due to a performance shutdown. The top-

down approach enables you to trace the situation to a certain SQL statement that took 500

milliseconds to execute. After the trace is completed, you can then see why the SQL statement

accounted for more than 30 percent of the total business process execution time.

WWW.MERCURY.COM 7

• Correlation: Correlation allows you to understand the business impact of your web application

activity by visually and conceptually linking back-end activity to end-user experience. “Bottom-up”

solutions, however, display performance information solely in terms of granular metrics, leaving

operators to do the guesswork as to how these bits of data translate into usable information about

business transaction performance.

• Efficient monitoring methodology: Agentless, or agent-based? Passive monitoring or active

monitoring? In order to obtain the maximum breadth of data collection and the most complete

analysis of J2EE activity while minimizing performance overhead, it is best to use a combination of

these approaches. However, most available solutions use only a passive agent-based approach. A

combined approach to monitoring will enable you to track problems in your J2EE infrastructure to

their root causes, to determine the health of your systems and applications, and to have a complete

analysis of the end-user experience, all with minimal overhead.

Mercury Business Availability Center: A Comprehensive Performance Management Solution for J2EE

Mercury Business Availability Center™ maximizes the performance and availability of J2EE applications

by providing a unified solution for your operations and application support teams to quickly monitor,

diagnose, and optimize production applications. It provides teams with visibility across user, business

process, application, and system tiers down to the component, method, and even code level. Ultimately,

high-performing mission-critical applications protect SLAs and the bottom line.

Mercury Business Availability Center provides an unprecedented breadth of application and technology

coverage, including J2EE, .Net, web services, ERP, CRM, and mainframe environments.

Business-Centric IT Management

Mercury Business Availability Center consists of three layers: applications, platform, and monitors. The

six applications are:

1. Mercury Service Level Management™: Enables you to manage service levels and provide SLA-

compliance reporting for complex business applications in distributed environments.

2. Mercury System Availability Management™ (with Mercury SiteScope®): Enables you to seamlessly

deploy and maintain an enterprise infrastructure monitoring solution to achieve 100-percent coverage.

3. Mercury Application Mapping™: Provides real-time visibility into the dynamic relationships between

your applications and the underlying infrastructure.

4. Mercury Application Management Analytics™: Transforms operational data into insight by delivering

advanced reports and ad-hoc analysis on Mercury and third-party data sources.

5. Mercury End User Management™: Proactively monitors application availability in real time and from

the end-user perspective.

6. Mercury Diagnostics™: Provides the industry’s first top-down lifecycle approach to seamlessly,

manage, monitor, diagnose, and resolve critical problems across the application lifecycle.

J2EE

WWW.MERCURY.COM 8

J2EE

These applications sit atop the Mercury Application Management Foundation™, which provides shared

workflow, data, scripts, and application/infrastructure monitors that integrate key application

management processes and leverage a best practices-based approach to problem resolutions. Mercury

Application Management Foundation enables your organization to deploy Mercury Business Availability

Center rapidly — at a lower TCO than traditional client/server solutions. Mercury offers centralized, web-

based administration and configuration for greater manageability, security, and scalability. It includes

embedded best practices and templates and a full suite of synthetic business process, real user, client

desktop and infrastructure monitors for more than 65 systems.

If you choose, Mercury Managed Services for Business Availability Center™ can provide a full

deployment of your Application Management Center of Excellence, monitored around the clock by

Mercury’s expert team. In addition to a pre-deployed architecture backed by database, application, and

security experts, Mercury provides ongoing mentoring and migration services to ensure your internal

team is ready to manage your own Application Management Center of Excellence. Mercury Managed

Services™ enables you to focus on critical IT and business initiatives rather than day-to-day system

administration, streamlines your application managed processes, and reduces Mercury Business

Availability Center’s TCO.

Effective J2EE Application Management: The Mercury Difference

Mercury Business Availability Center includes features specifically designed for monitoring, diagnostics,

and management of J2EE-based web applications. Working closely for a number of years with leading

IT vendors Sun, BEA, IBM, and Oracle, Mercury experts have designed industry-leading diagnostics

capabilities for J2EE applications.

With our flagship product Mercury Diagnostics for J2EE, Mercury can help you:

• Proactively detect problems before they affect customers.

• Rapidly isolate problems to system or application tiers.

• Pinpoint root causes to specific application components.

With Mercury Business Availability Center and Mercury Diagnostics for J2EE, your organization can

monitor the performance of its J2EE applications from one console, receive alerts when performance

discrepancies arise, identify problems, and diagnose their causes. It is the only solution that presents

performance and availability information in a top-down analytic manner; measures the end-user

experience and business processes 24x7; and correlates performance and availability issues to their

root causes, inside and outside the firewall, and within the application itself.

Mercury Diagnostics collects granular performance data from end-user performance transactions and

from components across the J2EE web infrastructure, then processes it into valuable performance,

availability, and service information. Once the performance data is collected, it is sent back to Mercury’s

central Diagnostics server for processing, storing, and correlation.

WWW.MERCURY.COM 9

J2EE

When a performance problem is detected within Mercury Business Availability Center, it alerts

operations groups via a pager, email, cell phone, or SNMP trap. This configurable alarm system can be

integrated with existing alert notification procedures to address issues as soon as they arise.

Additionally, Mercury Business Availability Center can take corrective action based on error recovery

scripts, automatically resolving performance issues. These capabilities help you further ensure maximum

uptime for your applications.

Mercury Diagnostics for J2EE offers real-time monitoring, transaction breakdown and triage analysis,

and deep diagnostics for the toughest J2EE problems.

360-Degree Real-Time Monitoring

Mercury Diagnostics first provides users with top-down viewing of the general health of your J2EE

application through integration with Mercury Business Availability Center dashboards. These dashboards

provide the high-level view on your web applications and systems, including status of your business

processes and transactions, health and

performance of application components, as

well as high-level status of the supporting

infrastructure: web servers, application servers,

and DB servers. Mercury Business Availability

Center Dashboard allows IT operators to quickly

identify end-user performance and availability

problems in J2EE production environments by

providing comprehensive monitoring across

end user, application, and system layers.

WWW.MERCURY.COM 10

Figure 3: Mercury Business Availability components.

Figure 4: J2EE Dashboard view provides high-level visibility into the overall health of J2EEapplications and the starting point for diagnostics.

J2EE

From there, application support engineers can

perform a deeper analysis of the performance

and availability of a specific web application and

then compare their findings to previously

established baselines and SLAs.

Triage Diagnostics

Mercury Diagnostics displays transaction

response times both from the client-side as well

as the server-side for a full performance picture.

The transaction response times are “broken

down” into the components measured from the

client machine (e.g., DNS Time, SSL Handshaking

Time, or Download Time) and the J2EE

components measured from the application

server (e.g., Servlet Time, Session EJB Time, or

Database Time). This allows for a quick and

intuitive view into exact bottleneck locations and

ensures that the problem is escalated to the

correct expert teams.

In Figure 6 we see the results of a “breakdown”

of four business transactions as they were

measured from the application server. The J2EE

Transaction Breakdown clearly shows that the

“Buy Book” transaction suffers from performance

degradation and that the Database Time is

accountable for 83 percent of the time for

transaction completion. “Drilling down” will lead

us directly to the problematic SQL statement to

further investigate the performance problem.

The way Mercury Diagnostics Center looks at every transaction and analyzes the factors determining its

performance is unique. No other monitoring tool can give IT managers and operators such an in-depth

reading of the J2EE application with minimal effort and knowledge of the application. Mercury Diagnostics

lets application support engineers quickly isolate the problems that affect the end users and gives them

the starting point for resolving the problem.

Deep Diagnostics — Solving the Toughest J2EE Performance Problems

Mercury Diagnostics collects granular performance and availability metrics on specific system and

application elements. This data is used for in-depth diagnosis of critical J2EE components such as

JDBC calls, Servlets, EJBs, EJB methods, and JNDI when a performance problem is identified.

WWW.MERCURY.COM 11

Figure 5: Transaction-breakdown-over-time view shows the time spent in each technologytier and helps isolate the layers at fault.

Figure 6: Call-tree view follows the transaction end-to-end in an easy-to-read, indentedtree format, and automatically highlights the critical path in red.

J2EE

For the toughest performance problems,

Mercury Diagnostics allows you to “dial-

up” the volume by turning on the deep

diagnostics capability and collect even

more granular metrics down to instance

and line of code levels.

Deep diagnostics captures data about

memory usage, threads, and individual

transaction instances — including

parameter passed — via Mercury’s

patented Total Trace technology. It

comes with pre-built reports designed

for analyzing threads and memory heap

through in-depth drill down analysis.

With unparalleled visibility, Mercury Diagnostics solves the most difficult problems in J2EE applications,

including memory leaks and memory thrashing, deadlock and synchronization problems, intermittent

response-time issues, and data-dependent problems.

Mercury Lifecycle Probe: Maximizing Visibility at Minimal Overhead

By combining agentless and agent-based data collection approaches, Mercury Diagnostics achieves a

remarkable balance between non-intrusive (yet sufficient) information collection and low overhead.

Mercury SiteScope agentless monitors are used for ongoing performance and availability monitoring as

well as trend analysis. For method-level diagnostics, the Mercury Lifecycle Probe uses an agent-based

instrumented data collection method. This combined monitoring approach makes the Mercury solution

optimal for production.

Mercury SiteScope monitors gather information such as CPU and memory usage, EJBs, J2C

connectors, JVM run time, and Servlet sessions, directly from the application server. These monitors are

custom-developed to support leading application servers, including BEA WebLogic, IBM WebSphere,

Oracle 9iAS, and Sun iPlanet. This agentless approach provides valuable metrics for correlating system

activity with the end-user experience while automatically analyzing the root-causes of any problems.

Plus it is easy to implement and readily deployed.

Whenever a serious performance problem is diagnosed, agent-based instrumentation is used in order

to perform a deeper analysis of the situation. The Mercury Lifecycle Probe is an innovative, patented

technology for instrumenting the bytecode of classes that are to be monitored. Bytecode

instrumentation provides valuable metrics of Servlets, JSPs, and JDBC load and response times, and

analyzes these metrics per server across all the J2EE tiers.

This unified probe is designed to collect application statistics across the application lifecycle, from

development and testing to production. Supporting the tools used at each stage of the lifecycle,

Mercury Lifecycle Probe is fully integrated with Mercury Performance Center, Mercury LoadRunner, and

WWW.MERCURY.COM 12

Figure 7: Memory-object-distribution report shows likely suspects for memory leaks and memorythrashing and allows for further drill-down into memory issues.

J2EE

Mercury Business Availability Center

offerings, for correlating end-user metrics

to application and system-level metrics.

This integration allows for automated

correlation between end-user experience

(e.g., check-out time) and the

performance of specific application and

system components (e.g., Session Beans).

Once a correlation has been made, your

IT staff can rapidly pinpoint the root

cause of a performance and availability

issue and move toward a quick resolution

of the problem.

Support for Clustered Environments

Realizing most production applications

run in clustered environments for

failover and load balancing, Mercury Diagnostics provides built in views for comparing performance of the

same end-user transaction across a cluster of application server instances. In a centralized location, you

can visually compare transaction and component performance across multiple JVMs, and quickly identify

load-balancing-related performance problems and isolate poor-performing application server instances.

Summary

Monitoring and web-based systems go hand-in-hand, so when assessing the importance of monitoring for

your enterprise, ask yourself how crucial your J2EE applications are to your business objectives. In today’s

world, where more and more critical applications are J2EE-based, a competitive monitoring solution is in

high demand by businesses that desire to maintain consistent, high-level application performance.

Mercury offers a comprehensive application management solution for J2EE that tracks application

availability and performance with a business-centric, top-down analytical approach. Mercury

Diagnostics for J2EE combined with Mercury Business Availability Center provides an immediately

readable view of the overall health of your J2EE application and infrastructure with the ability to drill-

down for an increasingly deep technical analysis of a problem’s root cause. The Mercury solution puts

the end-user first — from initial problem diagnosis to how alerts are triggered and prioritized. Mercury

correlates end-user experience with J2EE system activity and components, so that you understand the

business impact of your web application performance.

Mercury Diagnostics provides the industry’s first top-down, end-to-end approach to seamlessly manage,

monitor, diagnose, and resolve critical problems across the application lifecycle. Mercury Diagnostics is

designed to be used in both pre- and post-production environments to find deep-code and

configuration-level issues in J2EE, .NET, and ERP/CRM environments, including intermittent problems,

memory leaks, synchronization and deadlocks, and data-dependent issues.

WWW.MERCURY.COM 13

Figure 8: Compare-across-JVM view allows for quick visualization of load-balancing-related problemsin a clustered environment.

© 2005 Mercury Interactive Corporation. Patents pending. All rights reserved. Mercury Interactive, the Mercury logo, Mercury Business Availability Center, Mercury Managed Services, and Mercury Diagnostics for J2EE are trademarks ofMercury Interactive Corporation in the United States and/or other foreign countries. All other company, brand, and product names are marks of their respective holders. WP-1356-0305

Mercury is the global leader in business technology optimization (BTO). We are committed to helping customers optimize the business value of IT.WWW.MERCURY.COM