15.2 J2EE Monitoring and Profiling Tools

J2EE applications and J2SE applications are monitored and profiled differently. J2EE applications include all the bottlenecks that you find in J2SE applications, but they can also have more serious, system-wide resource contention bottlenecks. Contention bottlenecks occur when multiple objects try to use the same resource at the same time and extend across multiple VMs or to outside resources like databases. J2SE profilers essentially monitor and log various aspects of a single VM. To identify performance problems productively, J2EE profilers must monitor and log far more aspects of the overall J2EE system (including potentially multiple VMs).

15.2.1 Features to Look For

Here are some characteristics to look for when evaluating J2EE performance-monitoring tools.

Monitoring and logging components and their interfaces

J2EE tools must monitor and log all the important aspects of the J2EE system. Potential performance bottlenecks come mainly from three generic locations: processing within components, interfaces between components, and communication between components. Intercomponent communication overhead (for example, network transfers) is distinct from interface overhead (such as marshalling) or conversions (such as SQL request generation).

Low overhead

J2EE monitoring should impose only a low overhead on the J2EE system. Less than a 5% overhead is required for useful monitoring; a 1% overhead is ideal. Low-overhead performance monitoring lets you monitor constantly without worrying about how profiling overhead affects server behavior. This means that you can leave monitoring on at all times—in development systems, in test systems, and in production systems—without serious performance degradation. This situation does not occur with J2SE profilers, which have such a large overhead that running with a profiler on at all times would kill a project. J2SE profilers tend to have high overhead because it is considered acceptable, given their usage pattern. J2EE monitors are targeted at production systems as well as development, so they are generally designed to have lower overhead.

Requests mapped to methods

Monitoring should correlate incoming requests with subsequently monitored methods, components, and communications. It should be possible to easily correlate things like request-to-bean-to-db-queries so you can identify which requests are causing which bottlenecks. Without this capability, you can end up targeting many more bottlenecks than necessary or spending significant time trying to determine which requests map to which bottlenecks.

Log storage and granularity

Monitoring should store all data persistently so you can decouple analysis from running the server. Having things happen during a test run with no way to analyze the data later is annoying because one graph or another is displayed only in real time, with no logged data.

Logging is more important than saving performance by not logging. Monitor the resources used by the application. Identify spikes and trends that cause performance problems, and then alter the application to handle those problems. However, too fine a granularity of logging causes too much overhead. Try to keep logging overhead at 1%.

Scalability

The monitoring tool should scale with the application so you can deploy the monitoring with the application in the production environment.

15.2.2 J2EE Monitoring Tools

A separate class of monitoring tools has emerged in the last couple of years, dedicated to monitoring J2EE applications efficiently. These tools improve J2EE performance-tuning productivity significantly, and obtaining one for your project is worthwhile. You can obtain a list of such tools from http://www.JavaPerformanceTuning.com/resources.shtml. Should you wish to implement your own tool, you would need to add logging to all the main communication interfaces of the application, the transaction and session boundaries, the life-cycle boundaries (e.g., creation and destruction of EJBs), and request initiation and completion. A freely available logging tool designed to work with J2EE applications, such as Steve Souza's JAMon (see http://www.JavaPerformanceTuning.com/tools/jamon/index.shtml), can assist with this task.

Commercial J2EE monitoring products include additional analysis tools that help speed up the most complex part of J2EE tuning: analyzing the monitoring output.