Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
RE: Time measurement
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Mellergård, Daniel via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 18 Jan 2022 00:05:39 +0000
> It stores the TIMER_STARTSINGLE time-stamp when it switches to the CONNECT
> state for the handle (see https://everything.curl.dev/internals/statemachines)
It's a bit complicated to reference the concepts in the linked page to the different time properties available. But reading the source, it seems like there is no reliable way to convert the timestamps to a real world time? It would be nice if that was possible, at least for tracing purposes.
> I can't think of a reason why it should just because of HTTP/2, no.
> As you base your observations here on *one* server we can't know what it is related to! I can't rule out that there's a flaw somewhere here, but I'm not aware of any.
Ok, I found another one which also give a similar result. (It works, it's not that, but the timing does not show up as I expect.)
Examples:
https://imgur.com/a/BIigCT4
First image is http/1.1, second is http/2. (The timescale is different for the images.)
The "wait" is (starttransfer - pretransfer). The "transfer" is (total - starttransfer).
For http/2 there is mostly "wait"-time, but there is a /very/ short "transfer"-time following (sometimes ~0.5 ms, but sometimes as low as 50 usec). "wait" is about ~50ms typically.
It's only the initial transfers that has time of significance. A short DNS lookup up is done prior to "connect".
For http/1.1, the "transfer" is about ~50ms.
So it seems to me like the time for the transfer ends up in "wait" instead of "transfer" for http/2, but not for http/1.1.
This is the same for both the servers I tested (with http/2).
Date: Tue, 18 Jan 2022 00:05:39 +0000
> It stores the TIMER_STARTSINGLE time-stamp when it switches to the CONNECT
> state for the handle (see https://everything.curl.dev/internals/statemachines)
It's a bit complicated to reference the concepts in the linked page to the different time properties available. But reading the source, it seems like there is no reliable way to convert the timestamps to a real world time? It would be nice if that was possible, at least for tracing purposes.
> I can't think of a reason why it should just because of HTTP/2, no.
> As you base your observations here on *one* server we can't know what it is related to! I can't rule out that there's a flaw somewhere here, but I'm not aware of any.
Ok, I found another one which also give a similar result. (It works, it's not that, but the timing does not show up as I expect.)
Examples:
https://imgur.com/a/BIigCT4
First image is http/1.1, second is http/2. (The timescale is different for the images.)
The "wait" is (starttransfer - pretransfer). The "transfer" is (total - starttransfer).
For http/2 there is mostly "wait"-time, but there is a /very/ short "transfer"-time following (sometimes ~0.5 ms, but sometimes as low as 50 usec). "wait" is about ~50ms typically.
It's only the initial transfers that has time of significance. A short DNS lookup up is done prior to "connect".
For http/1.1, the "transfer" is about ~50ms.
So it seems to me like the time for the transfer ends up in "wait" instead of "transfer" for http/2, but not for http/1.1.
This is the same for both the servers I tested (with http/2).
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-01-18