Understanding Elapsed Time in Page Action Purepaths
HPage Action Preview Case 020513.dtsello, I am looking at a page action purepath which has a response time of 7671ms. The corresponding server time is 1043.58ms, client time is 0ms, and network time is 556.42ms.
Looking at the method detail, for the 3rd web request, its showing an elapsed time of 7257.79ms. Where is this elapsed time being spent? on the server side or the client side? I don't understand how he elapsed time works when looking at Page Actions and if contains server time, network time, and client time?
I've attached a screen shot and exported the purepath.
OK I understand now that the End to End Response refers to the beakdown of Page Action Total Execution Time. But from an end user's perspective, I would think what we really care about is the Response Time, since this is what they're really experiencing. Is there a way to get a breakdown of server, network, and client time for the Response Time?
Another question is why does the end to end response time say that server time is 66%, which equates to 5062.86ms, but then on the Server Time column, it only shows 1043.58ms?
Good question. The times we show up there in the top table refer to the time breakdown of the Page Action Total Execution Time - and not the Total Response Time. Check out the Total Exec Column in the Tree. If you sum up the Exec Time for the Server-Side Requests you end up with 1043ms
The Response Time is much higher in your case - but - thats just because your page downloads a second Preview.aspx at a later point of the page life cycle
Andi
Thanks Andreas.
Does it make sense that the client time is 0? Should client time not include activities executing on the browser?
The Client Time gets calculated:
Client Time = "Exec Total Time" of the Page Action - Server Time - Network Time
Exec Total Time is the time from start to end of the action that triggered the Page Action. When talking about a Page Action that was triggered by loading a page the Exec Total Time gets measured from start until the onLoad event handler is done. If it gets triggered from a JavaScript Handler, e.g: jQuery click event handler - the Exec Total Time is from start to end of that event handler.
Server Time is the time spent on the server. We take this by looking at the server side PurePath Execution Times.
Network Time is available when you have bandwidth calculation turned on. It is a calculated "estimate" of the actual time spent on the network.
So - how can it be that Client Time is 0? If there is no real client activity going on, e.g: static pages. I can see from your screenshot that you have several that show Client Time with 0. Click on it and check the PurePath - I am sure you will see server-side PurePaths that span the whole page action
Andi,
could we get how dynaTrace calculates network time from bandwidth.
-Sreerag
There is some information about this in the documentation. Start here: User Experience Management & User Action PurePaths
Hi Melanie
The Page Action PurePath shows all the activities for a single Page Action. This mainly includes web requests such as .aspx, .js or other resource files. The Elapsed Time indicates when a particular activity (or web request) started relativ to the Start of the Page Action.
In your case it seems that the Total Page Action took 7671ms. The first download of Preview.aspx started after 1.13ms and took 633ms. Then another resources was downloaded starting after 717ms. This can be explained because the browser first had to download the content of Preview.aspx. After parsing that HTML content it continued downloading the embedded resource from your Telerik Library. That download took 82ms. Then it seems that the browser waited for ~6450ms until it sent another request to Preview.aspx. How can this be explained? Either some long running JavaScript. Could also be something that blocked the browser from the next download, e.g: a message box prompting the user for some input, ...
What is interesting is that the onLoad event handler was triggered after 1.4 seconds and took 62ms to execute. That means that really something that was going on in the background (some JavaScript) or a waiting on a user interaction caused the browser to wait that long to send the next Preview.aspx request.
I hope this makes sense.
