In the PurePath table the breakdown is shown for the overall time spent in io, wait, sync, suspension, CPU for that entire PurePath.
In the PurePath tree it shows the breakdown per node/event instead. Each one of them eventually makes up the overall breakdown shown in the PurePath table.
Hey Chris 🙂
Thanks for clearing that up. Actually I am wondering how does the 50-50 percentage of wait time and io-time comes from? Why can't it be say, 60-40 or 70-30? Normally what I see is pretty much that all the entries in the PP-tree sum up together then you'll get roughly AROUND the percentage distribution in the PP there.
But for this one, I just really can't wrap my head around it.
Hey there! 😃
Right, in most cases you'll see the same pattern for the breakdown in the PurePath tree versus the breakdown for the entire PurePath. But let's first talk about how the breakdown for both is calculated. The individual breakdown is quite explanatory; the sensors collect the data and AppMon will calculate the breakdown for each node/event. These individual breakdown will then be summed up to the PurePath breakdown. Here, the law of average actually plays a part - the pattern of individual breakdown will influence the resultant overall PurePath breakdown. For example, if I have a PurePath with 3 events (1st - 50% io 50% suspension, 2nd - 100% io, 3rd - 100% wait), then probably my overall PurePath breakdown would be 50% io, 33% wait, 16% suspension.
In your case, seems like the half of the nodes/events is 100% io and the other half is 100% wait. So that adds up to 50% io and 50% wait in the overall breakdown - speaking from a purely statistical perspective. If we want to understand why this goes off the usual path whereby a PurePath breakdown should be more or less the same pattern as individual breakdowns, first we need to understand how the application works. Looking at the screenshot you provided, nodes come from different tiers/API and they make sync/async calls or even making web requests. The service(...) having 100% wait time as the subsequent submit(...) going down to executeMethod(...) are having 100% io time. This makes sense as they are from different tiers/API and one would be waiting while the other is doing io.