The metrics you choose to view depend on your
application domain, your code, the demands for the application, and
the operating environment. Look at all of the available ones, and
analyze at least a few of the topmost entries.
Whenever possible, the console visualizers present
all metrics sorted in decreasing order of resources used. This places
the largest resource users at the top of the screen. Evaluate them
knowing your application and its characteristics. Use your intuition.
If you find anything that you cannot explain, take the time to investigate
and find the cause. A high level of resource consumption may be legitimate,
but it can also be an indication of a performance bottleneck.
Looking at the Data from the Bottom Up |
 |
One approach to performance analysis is the bottom-up
technique. It can be used even if you are not very familiar with the
application. Look at the following metrics, if available:
If you find a method, or a few methods that consume
much time, they can become a target for your performance tuning. Similarly,
if a method is called excessively many times, check to see if you
can reduce the number of calls.
This will often require investigating the invocation
context for the method in question. Mark the
method , and find it later in the corresponding call graph.
(See Using Call Graph Trees).
Looking at the Data from the Top Down |
 |
An alternative, top-down approach to profile data
analysis is to start from the call graph based on Clock or CPU time and continue expanding the topmost nodes until you
find a method or multiple methods which implement high-level operations
characteristic for your application (that is, are responsible for
transaction processing). By expanding this node you can see how this
high-level operation splits its work among the methods it calls. If
your intuition tells you that the numbers do not look appropriate
or correct, continue expanding the nodes that consume too much time
to find the reason for the anomaly.
Looking for Inefficiencies in Memory Usage |
 |
Large applications put a lot of stress on all
components of the computing system. One strategy for understanding
the behavior of your application is to look at how well the application
is working within the boundaries set for heap size and the selected
garbage collection type in use by the JVM. Adjusting heap size and
garbage collection type can improve memory usage and work efficiency
when adjusted to the demands of a particular application. For a view
of memory usage and object metrics, see Profile Memory and/or Heap Activity. See Analyzing Garbage Collection Data to obtain a detailed view of the impact
of GC activity on the system.
Operating system performance, third-party software
performance, the bandwidth of the I/O subsystem, and so on, all affect
application performance. Analyzing these factors is beyond the scope
of this tool, but it should always remain on your agenda.