Interpreting Captured Trace Data
Using Application Vantage 11.5 we have captured a user opening Outlook on a PC. As well as loading normal emails into Outllok, it contains a plugin to connect to a third party company via the internet. The whole process has been reported as slow by the user.
We have tidied up the trace and can see it connects to a local domain controller for authentication and DNS, but remote servers for Exchange and Proxy. The Perfomance Overview shows the largest time as being Client processing at 105 seconds. Followed by Proxy processing at 40 seconds. We have then looked in the Perfomance Time Predictor page and found the following:-
We can see that the client takes up around 65% of the response time (70.6 seconds), with the Proxt server being the majority of the rest (33.8 seconds).. Yet on the Total Resource Time the client only takes a tiny fraction of time (1.1 seconds) compared to the proxy (62.2 seconds).
We are not clear what this is telling us. How can the client Response time be so large, but the Resource Time Node Busy be so small?
Thank you in advance.
Mark
Best Answer
Hi Mark,
First, a little background. The Response Time Predictor used two different algorithms to allocate time; the Response Time Breakdown is a 100% view, the Node Busy Time is a parallel view. These differed from the main analysis algorithms - the Performance Overview and the CNS view - and were based on a model of the transaction used for prediction. The results, while generally easy to understand for simple traces, quickly become difficult to explain for more complex traces. This is one of the reasons we are replacing the old RTP with a new RTP - GUI and algorithms - in more current versions of the product.
If you would like, I can try to evaluate the trace you are using if it is possible to send me a copy. Maybe I can arrive at a reasonable explanation that way. gary.kaiser@dynatrace.com
Best Answer
Hi Mark,
In Transaction Trace (now Dynatrace Network Analyzer), we allocate transaction time using two general methods. The first method uses a 100% view, where the sum of the delays will equal the total transaction time; this is used for both the CNS View and the old RTP Response Time Breakdown.
For single-threaded transactions, this 100% method is quite straightforward; only one delay component is active at any given time. Consider a client-server database application; the client issues a query and must wait for the response before executing the next query. The client wait time is comprised of the time it takes the request to reach the server (client node sending), server processing, and the time it takes the response to reach the client (server node sending). Only once the client receives the response can it continue to execute its program logic (client processing). Node sending delays may be further broken down into bandwidth, latency, congestion, or TCP flow control.
For multi-threaded transactions, there are points in time where multiple delay components are active at the same time. Consider a web application; the client may be downloading content from one server at the same time another server (or even the same server) is processing a request for a javascript file. This parallelism means that the 100% approach requires the use of a critical path algorithm to determine which delay – network or server processing in the example – takes precedence.
The second method is a parallel view, where all delays are fully counted; this is used for both the Performance Overview and the old RTP Total Resource Time. For a single threaded transaction, the results will be basically the same as a 100% view (because there is no parallelism). But for multi-threaded transactions, the parallel view will show more detail about individual delays. This is particularly evident in the Performance Overview, where node processing, node sending, network bandwidth and network latency values will add up to greater than the total task duration. Double-clicking on the Node Processing or Node Sending bar, for example, lists all of the individually-measured processing or sending delays – in their entirety, even if there might have been other delays occurring at the same time. The Node Busy and Network Busy bars in the old RTP use a similar method, identifying the total time each of these delay categories is “active” independent of any other delays.
Gary
Hi Gary
Thank you for the explanation. Most helpful. However, it does lead me to another issue. If the Performance Overview and the old RTP Total Resource Time use the same method to allocate transaction time, should the figures in both views match?
In an example I have the following:-
Performance Overview shows
Client Processing = 3.33s and Client Sending = 0.05s
Server Processing = 6.46 and Server Sending = 4.51s
RTP Total Resource Time shows
Client Processing = 5.183s and Client Sending = 0.00s
Server Processing = 6.475 and Server Sending = 3.144s
So whilst 2 of the 4 values closely match, the other 2 differ greatly. Do you know why this is?
Thank you.
Mark
Hi Gary
Following on from this, could you possibly give a generic explanation of :-
Response Time Breakdown - What does it mean and what does it show?
Total Resource Time - Again, what does it mean and what does it show? Especially Node Busy Time.
Thanks
Mark
Hi Gary
Thank you for your response. We are almost at the point of implementing Transaction Trace Analysis 12.2, so will take a look with that.
As regards passing over the trace, I would need to get approval as it would contain sensitive information.
Thanks
Mark
