Tips on Using the New Relic APM Thread Profiler

a sample scenario

let’s consider a scenario in which the thread profiler can help.

in this scenario, you notice that your application is performing poorly. you look at the application’s overview dashboard and see that two transactions, /owners (get) and /vets (get) , are much slower than the rest. to help figure out why these transactions are so slow, you select a transaction trace in which /owners (get) took 7.5 seconds to complete.

the transaction trace tells you that 92% of the time (almost 7 seconds) was spent in ownerslist.jsp . you want to know what the code could possibly be doing that would take so long, so you select the trace details tab.

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:

1. you can debug the dandelion datatables component (or contact its author) to figure out why it’s performing poorly.
2. 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!