[ Team LiB ] Previous Section Next Section

Chapter 2. Profiling Tools

If you only have a hammer, you tend to see every problem as a nail.

—Abraham Maslow

Before you can tune your application, you need tools that will help you find the bottlenecks in the code. I have used many different tools for performance tuning, and so far I have found the commercially available profilers to be the most useful. You can easily find several of these, together with reviews, by searching the Web using "java+optimi" and "java+profile" as your search term or by checking various computer magazines. I also maintain a list at http://www.JavaPerformanceTuning.com/resources.shtml. These tools are usually available free for an evaluation period, and you can quickly tell which you prefer using. If your budget covers it, it is worth getting several profilers: they often have complementary features and provide different details about the running code. I have included a list of profilers in Chapter 19.

All profilers have some weaknesses, especially when you want to customize them to focus on particular aspects of the application. Another general problem with profilers is that they frequently fail to work in nonstandard environments. Nonstandard environments should be rare, considering Java's emphasis on standardization, but most profiling tools work at the VM level, and there is not currently a VM profiling standard,[1] so incompatibilities do occur. Even if a VM profiling standard is finalized, I expect there will be some nonstandard VMs you may have to use, possibly a specialized VM of some sort—there are already many of these.

[1] The Java Virtual Machine Profiler Interface (JVMPI) was introduced in 1.2, but it is only experimental and subject to change, and looks like it will stay that way officially. There are now two expert groups, JSR 163 and JSR 174, addressing JVM profiling and monitoring issues, and the results of these two expert groups should eventually supersede JVMPI.

When tuning, I normally use one of the commercial profiling tools, and on occasion when the tools do not meet my needs, I fall back on a variation of one of the custom tools and information-extraction methods presented in this chapter. Where a particular VM offers extra APIs that tell you about some running characteristics of your application, these custom tools are essential to access those extra APIs. Using a professional profiler and the proprietary tools covered in this chapter, you will have enough information to figure out where problems lie and how to resolve them. When necessary, you can successfully tune without a professional profiler, as the Sun VM contains a basic profiler, which I cover in this chapter. However, this option is not ideal for the most rapid tuning.

From JDK 1.2, Java specifies a VM-level interface, consisting of C function calls, that allows some external control over the VM. These calls provide monitoring and control over events in the VM, allowing an application to query the VM and to be notified about thread activity, object creation, garbage collection, method call stack, etc. These are the calls required to create a profiler. The interface is intended to standardize the calls to the VM made by a profiler, so any profiler works with any VM that supports the JVMPI standard. However, in JDK 1.2, the JVMPI is experimental and subject to change.

In addition to Java-specific profilers, there are other more generic tools that can be useful for profiling:

  • J2EE server-side monitors, useful to monitor server performance both in development and in production

  • Network packet sniffers (both hardware and software types, e.g., netstat)

  • Process and thread-listing utilities (top and ps on Unix; the task manager and performance monitor on Windows)

  • System performance measuring utilities (vmstat, iostat, sar, top on Unix; the task manager and performance monitor on Windows)

    Previous Section Next Section