Interpreting Captured Trace Data

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

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