Tips on Using the New Relic APM Thread Profiler
Get to know New Relic's APM Thread profiler, which helps determine where your code spends its time.
Join the DZone community and get the full member experience.Join For Free
in order to add as little overhead as possible, new relic’s language agents are selective about the code they instrument. as a result, new relic may occasionally report that a particular transaction consumed a significant amount of time, but doesn’t provide details about exactly where the code spent its time. in such cases, new relic’s thread profiler feature may be helpful.
a sample scenario
let’s consider a scenario in which the thread profiler can help.
you drill down further, hoping to see what code ownerslist.jsp is calling, but you hit a dead end.all the transaction trace can tell you is that ownerslist.jsp executed some “application code.” not very helpful.
hovering your cursor over the question mark icon, you learn that new relic can’t provide more detail about this transaction because the code in question is not instrumented by the language agent. (for information about why this might happen, see the sections application code in traces and partial traces in the new relic documentation on transaction trace details .)
this sounds like a job for the thread profiler!while new relic’s language agents work by injecting instrumentation into your code, the thread profiler relies on sampling: it periodically takes a snapshot of your application’s call stack. this allows it to see even uninstrumented code that is invisible to the language agent.
to use the thread profiler, you select the application instance you wish to profile, the length of time the profiler should watch it, and click the start profiler button. when the thread profiling session is finished, you may view the results by selecting its time stamp or application instance name.hint: you can remove “noise” from the thread profile result by selecting filter outliers and clicking the refresh tree button. this hides methods that occur very infrequently, helping to focus your attention on the methods that are more likely to affect your application’s performance. the result page shows you how frequently each method appears in the collected call-stack samples.
remember, your goal here is to figure out what ownerslist.jsp is doing that’s taking so much time, so you expand the results tree and search for “ownerslist.” there it is!
the thread profile reveals that ownerslist.jsp is calling a component named com.github.dandelion.datatables , which is not instrumented by the new relic language agent.
now that you’ve found the culprit, you have a couple of options:
- you can debug the dandelion datatables component (or contact its author) to figure out why it’s performing poorly.
- you can implement custom instrumentation to tell the new relic language agent to instrument dandelion datatables from now on.
in this sample scenario, new relic’s thread profiler gave you x-ray vision into your code, allowing you to see inside a black-box transaction and figure out where the code was spending its time. that capability can come in handy in many real-world situations, too!
Published at DZone with permission of Phil Weber, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.