Purepath is single instance of transaction. It is hard to have general idea about performance issues based on single transaction that can but not must be representative. I always start from instrastructure (hosts / proceses) -> Services (looking for transactions that are slower than XX seconds, failed transactions). That I'm using service flow for checking if other services are root cause of fail or response time degradation. Than I'm going to the place where the root cause is located and checking Response Time Hotspots / Method hotspots / Details of failures and purepaths. In most cases this is path I'm following during loadtests for example. Systems are handling thousands of transactions so you have yo use advantages of dynatrace to have full scope view.
Thanks for your reply.
I am really getting the big picture about the way to begin the analysis.
In your reply, you talked about the Method hotspots. On that dashlet, the methods are ordered by Exec Sum. I assume, it is the sum of all response time of a particular method each time it is called.
Why do you think is method hotspot order based on the sum ?
What can be the real take away from the method hotspot dashlet ? (To be honest with you, I do not tend to look at it)
Method hotspots shows number of CPU samples that contains particular methods. It’s not related to time that you can calculate in ms but you know that those methods was on cpu for long time or really often. I use it for looking for slowdowns in uninstrumented parts of code. I download source code from this view as well. If I need to make PurePaths more complete I’m making request attributes or custom services based on methods registered in this dashboard.