ExtraHop collects a number of different timing metrics that are useful in different situations. Here’s a high level look at each.
Processing Time- this calculates the time from the last packet of the request to the first packet of the response. Essentially it is a measurement of how long a server takes to understand and process a request and assemble the contents of the response (“server think time”). This is useful for determining whether a server (or application code on a server) is contributing to latency vs the network.
Round-Trip Time (RTT)- this measures, at the most basic level, the time it takes for a packet to go from one endpoint to another on the wire and for the corresponding ACK to return on the wire. When we calculate RTT, we actually abstract out the processing time and just measure the time that the packets spent on the wire. Here’s a detailed post on how ExtraHop calculates TCP RTT . [Update- note that ExtraHop RTT is L4 (TCP) whereas ping-based RTT is L3]
Request Transfer Time- this measures how long it takes all the packets that make up a request to travel from the client to the server on the wire. This is still a network-centric timing metric, but is different from RTT.
Response Transfer Time- this measures how long it takes all the packets that make up a response to travel from the server to the client on the wire.
These are how these metrics are often shown in ExtraHop-
or like this in Records-
However, sometime you may see results that show something like RTT and yet no process time is recorded- something like this
What is happening here is that probably means that there was a desync, or gap, on that particular flow. When we have gaps in the flow we usually try to reassemble the flow so we can have complete metrics. However, some L7 protocols cannot be reassembled after a gap due to the way they communicate. In this case it means that we can continue to track L4 metrics on the flow (like RTT) and we will lose the ability to calculate L7 metrics (like Processing Time).