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.
Printable version
