I got the following information from an old post.
Thanks Babar for your support,
Then, this can lead to the slowness of an application,right?? Because, Dynatrace captures this whenever there is slowness in this application. How can i explain to the application owner since this happens once and is the most problem they face?
Right click on the purepath -> sequence diagram to check the flow of calls and response time/method hotpot to find the method which contributes for high response time.
Also you can check the call tree in the bottom of the purepath which you selected in snapshot to see method/request which took time and switch tab to transaction flow to see the tiers involved and each tier time spent for the specific request.
Its clear that there are high wait and CPU consuming methods which will be visible in PurePath tree (more clearly if auto-instrument is enabled). Could you share the full purepath snapshot?
Also, Select all PurePath, right click, Drill Down to Method Hotspot for Quick diagnostic.
How much slower is this as compared with what you're normally seeing?
And based on the PurePath hotspots in the top right it doesn't look like any one step is taking up all of the time so it is likely several contributing together. The purple-ish chunks kind of stand out from the rest, if you click on those it will take you to the step in the tree where that is at. You can also click on the transaction flow tab to see if any one tier is taking a lot of time. If you have older purepaths from when the response times were quicker you can also select one and compare it with one of these.
First of all, as shown in the snapshot, the servlet request is slow. Which further is due to slow web service.
Secondly, you should never conclude just using couple of purepath sample.
1. Its always good you navigate your slowness investigation from the OOTB dashboard whenever there is slowness. In my experience the method hotspot will point out what layer and instance is contributing to slowness in your application that too gives time caused by CPU, WAIT, IO, GC etc.
2. You need to approach step by step, I mean clearly it shows that some bad coding is gulping up your cpu, some another bad queuing middleware is choking your layers, some anothe bad piece of code is causing high sync time. This way the whole issue is created by such nasties.
3. This approach will not pin point the exact problem BUT noting these thing down and fixing these thing step by step is the way it should go.
Hence keep taking notes of all observation and then conclude for RCA. Because it does not have to have a single root cause but many issues contributing and frictioning each other. Regards, Rajesh.
People (app owners) might ride on your neck for single ultimate grand cause. It doesn't have to have a single root cause, there can be multiple causes.
Some biases people fell into:
"It's just cascading effect, ignore it."
"Tell me one final thing to fix."
For more best practices keep reading APM Dt blogs.
Actually looking at your initial screenshot do you know this is even an issue? Are you seeing slower times? EDIT - reread your initial post, so it seems it is slower. I'll leave this info regardless:
The breakdown column will provide details like that regardless of if there is an issue - it will attribute the response time to CPU, suspension, sync, wait, or IO adding up to 100%. This breakdown will show up regardless of whether the response time is 1 ms or an hour - it alone doesn't indicate any issue.