What do the timing metrics mean, exactly?

[TrevorBurnham]

I'm trying to use Proxyman to help diagnose some performance issues. However, I don't really understand what a timing breakdown like this one means:

I don't see any definitions for "Request time" and "Response time" in the documentation. Giving the quantities here, I'm guessing that:

1. "Request time" is the time elapsed from the request being sent until the first byte of the response was received, minus the "Latency"
2. "Response time" is the time elapsed from the first byte of the response being received until the response was fully received.

Is that right? Also, how is Proxyman able to determine "Latency"? TCP packet timestamps? And what's the difference between "Duration" and "Duration (exact)"?

For performance investigations, it would be really helpful for Proxyman to provide a more detailed breakdown of network timing. For example, Proxyman can tell me that this request used TLS 1.3, but I don't know how many round trips the TLS handshake took: With TLS 1.3 it could be zero, one, or two. Ideally I'd want to see how many round trips the request involved, how long each one took, and what the purpose of each round trip was (e.g. which requests were part of the TLS handshake and which were to send the request itself).

Information at the transport layer level could also be useful: Did the request use TCP, or QUIC? When was each packet sent/received?

[NghiaTranUIT]

Hi @TrevorBurnham,

• Request Time: is the total duration that the request is sent from the client to your server (from the first byte to the end of the body)
• Response Time: Similar to the Request Time, but for the Response.
• Duration is the total time when receiving the first byte of your Request (from your client) to the end of the Response (to your Client). It can be rounded to easier to read.
• Latency is accounted for SSL negotiation and the time Proxyman connects to your server.
• Duration (exact) is exact time for the duration (not rounded)

[TrevorBurnham]

Thanks for the response! I still don't fully understand the figures, though.

For context, the screenshot above is for a small request (the request and response are each ~1KB), and ping reports a network latency to the server of ~30ms. So I'd expect the whole request process to go something like:

1. A TCP connection is established, which requires one round trip (~30ms).
2. A TLS 1.3 connection is established, which requires another round trip (~30ms).
3. The request is sent over the TLS connection (this part should take <1ms).
4. I receive the ACK for the request, which requires another round trip (~30ms).
5. After some amount of time, I receive the response from the server.

I don't know how the "Request time," "Response time," and "Latency" figures map to that process, which makes it difficult to figure out which optimizations are worth performing. In particular, it seems like a lot of things are being included in the "Request time" bucket that could be usefully separated out.

[NghiaTranUIT]

In particular, it seems like a lot of things are being included in the "Request time" bucket that could be usefully separated out.

The Request Time includes:

• Time from your client first connects to Proxyman (local)
• TLS handshake from your Client to Proxyman
• Time Proxyman connect to your server + TLS Handshake
• Time to fully receive your requests (Client -> Proxyman), and time to send everything to the server (Proxyman to your Server).

It's decided that way to be compatible with other tools.

If Request Time only counts the time from your client -> Proxyman. It's super fast because it all happens on your local machine. (likely < 1ms)