Profiling Using Yourkit


By profiling, we mean the traditional concept of performance analysis. This involves executing the application while instrumented with performance probes (timing and counters) so that one can determine where the time is spent and focus on bottlenecks ("hotspots"). There are typically 2 modes: sampling mode and tracing mode. Sampling is less intrusive because it tries to limit its capture to just some representitive results. Tracing mode is very intrusive, because it gives exact counts and timing. Sampling mode can give you an idea of what is going on but often the details are fuzzy/inexact. Tracing mode gives you the full picture but the application runs very slowly. The results are relatively correct but the time amounts are much longer than when there is no tracing.

Although the VisualVM is included in the JDK, it is not very useful for tracing mode profiling. We have found that in real applications, sometimes VisualVM will just freeze itself and the application. CPU sampling mode works ok and is useful for finding high-level hot spots, though it can be misleading at times.

In our experience, Yourkit is significantly better for profiling. It requires running the target JVM with an agent. The absolute times are greatly inflated because of the profiling overhead, but the call counts and relative times seem quite accurate.

How to Enable Tracing


Analysis Tips

Merged Callees

A very useful view is the "Merged Callees" tree, where you can manually expand the nodes that are time consuming. This is taken from a CPU profiling snapshot, captured in tracing mode (not async sampling mode). This is the slowest mode, but it's not too bad when you are tracing a well-defined, relatively short operation, like opening a single screen.

After capturing and opening the snapshot, open either the "Hot spots" or the "Method list" views, select a method in the top part of the screen, then select the "Merged Callees" view in the bottom part of the screen. From there, you can open/close individual nodes in the tree.

How to Find a Problematic Method

What is the criteria used to find a problematic method in the Method List? For example, if it is not mentioned in the HotSpot window?

I am not sure my methodology is 100% correct. I may be missing things with this approach, but that being said...

I have been looking for methods which consume higher than some threshold of the overall, aggregate time. That threshold started at anywhere between 5-10% (which generally are represented in the Hot spots view. But as we've fixed things and the bottlenecks are becoming smaller, I'm now looking for methods that are at least 1%.

Also, I mostly ignore methods whose main purpose it is to invoke converted business logic, like the ControlFlowOps.invoke*() methods, or BlockManager workers. I find that these are hard to navigate, because the call tree from those points downward is very deep.

I'm looking for methods which actually result in work which takes a long time in FWD itself, or in third party code we can modify (e.g., H2). I don't know if this approach is ideal, or whether it is making me miss some opportunities for optimization, but it is what I have been doing so far.

I've also looked at the SQL information ("Events -> Events by Table"), to find slow queries, to see if there is something wrong with the way the query is formed. YourKit records the SQL that was executed, but unfortunately not the substitution parameters that were passed.

© 2020 Golden Code Development Corporation. ALL RIGHTS RESERVED.