{"id":20476,"date":"2023-12-31T11:16:00","date_gmt":"2023-12-31T11:16:00","guid":{"rendered":"https:\/\/dataforpublicgood.org.in\/?p=20476"},"modified":"2025-01-24T11:19:40","modified_gmt":"2025-01-24T11:19:40","slug":"profiling-java-applications-using-async-profiler-and-flame-graphs","status":"publish","type":"post","link":"https:\/\/dataforpublicgood.org.in\/cdpg\/blog\/profiling-java-applications-using-async-profiler-and-flame-graphs\/","title":{"rendered":"Profiling Java Applications using Async Profiler and Flame Graphs"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t

Introduction<\/h2>

A key requirement of a data exchange is good platform performance. Deciding what is good performance is usually determined by the data characteristics and query statistics. Serving a hundred small JSON documents per second may be considered slow, while serving a hundred 5-minute-long video files per second could be considered as excellent performance. There are various metrics which can be used to describe the performance of a data exchange such as requests per second. Different performance testing strategies are used to find bottlenecks in platforms which do not meet adequate performance metrics. We often turn to debuggers (or print statements) when trying to fix logic bugs when writing applications. But what happens when we find performance issues when load testing or stress testing the application? Using a debugger or observing debug logs may help, but they may not be enough. If a close reading of the code does not help in finding the issue, profiling the application would be the next best step to take.
This article aims to provide a technical overview to profile Java applications using Async Profiler and how to interpret the results in the form of flame graphs.<\/p>

Async Profiler<\/h3>

Async Profiler is the profiler we are going to use. Apart from being actively developed and easy to use, the main advantage of Async Profiler is that it avoids safepoint bias when profiling. Understanding what safepoints in the JVM are is beyond the scope of this article, so take a look at this article to learn more about them.<\/p>

Flame Graphs<\/h3>

After profiling the application, we need a way to interpret the results. Flame graphs were pioneered by Brendan Gregg as an intuitive way to visualize and interact with profiling results. I highly recommend his article that explains the motivations behind the creation of flame graphs and how to gather insights from them.<\/p>

public<\/span> class<\/span> FlameTest {<\/span>\n<\/span>\n  public<\/span> static<\/span> void<\/span> divisibleByTwo<\/span>() {<\/span>\n    System<\/span>.out<\/span>.println<\/span>(\"Divisible by 2\"<\/span>);<\/span>\n    return<\/span>;<\/span>\n  }<\/span>\n<\/span>\n  public<\/span> static<\/span> void<\/span> divisibleByFive<\/span>() {<\/span>\n    System<\/span>.out<\/span>.println<\/span>(\"Divisible by 5\"<\/span>);<\/span>\n    return<\/span>;<\/span>\n  }<\/span>\n<\/span>\n  public<\/span> static<\/span> void<\/span> main<\/span>(String<\/span>[] args) {<\/span>\n    int<\/span> i = 1<\/span>;<\/span>\n<\/span>\n    while<\/span> (i < 10000<\/span>) {<\/span>\n      if<\/span> (i % 2<\/span> == 0<\/span>) {<\/span>\n        divisibleByTwo<\/span>();<\/span>\n      } else<\/span> if<\/span> (i % 5<\/span> == 0<\/span>) {<\/span>\n        divisibleByFive<\/span>();<\/span>\n      }<\/span>\n<\/span>\n      i++;<\/span>\n    }<\/span>\n  }<\/span>\n}<\/span><\/code><\/pre><\/div>
This simple program iterates over numbers from 1 to 10000, checks if the given number is divisible by 2 or by 5. Accordingly, a method divisibleByTwo or divisibleByFive is called. You can see the flame graph we obtained from profiling the application using Async Profiler.<\/p>
\"\"<\/p>
Fig:<\/em><\/strong> Flame graph generated from profiling <\/em>FlameTest<\/em><\/p>
Observe the different method names that are present across the graph. Methods that are on top of each other are nested method calls. There are the methods that we have written like divisibleByTwo and divisibleByFive, internal Java methods and Linux system calls.
As a simple rule-of-thumb, the wider a method is on the x-axis, the more time it spent being processed by the CPU during profiling. Similarly, taller lists of functions denote deeply-nested method calls.
Notice that divisibleByTwo is much larger than divisibleByFive in the flame graph. Since there are more numbers divisible by 2 than 5 from 1 to 10000, divisibleByTwo was present on the CPU more often than divisbleByFive.<\/p>
In the way that we notice expected behaviour when profiling this program, we can discover unexpected behaviour when profiling real world applications.<\/p>
Setting up and using Async Profiler<\/h2>
You can download async profiler from here<\/a> for the appropriate architecture. Once downloaded and unzipped, the profiler.sh script is what we would use.<\/p>