cURL / Mailing Lists / curl-library / Single Mail

curl-library

Making sense of CURLINFO_*_TIME values

From: Peter Schwartz <peter+curl-library_at_spotfront.com>
Date: Wed, 24 Jul 2013 09:07:18 -0400

Hello,

We use libcurl to connect to a vendor's HTTP API. We've been having
some trouble with it, and they asked us to provide them with some
timing data to help their debugging efforts. To do this, I'm going to
start logging some/all of the CURLINFO_*_TIME values, but I found that
the documentation
(http://curl.haxx.se/libcurl/c/curl_easy_getinfo.html) left me with
some questions about what exactly those values represented, and I
haven't yet been able to find adequate clarification.

I'm hoping that this group can help me answer those questions by
confirming or correcting the following assumptions I've made:

1. CURLINFO_NAMELOOKUP_TIME is the time it takes from the start of a
transaction until the client has resolved the DNS for the remote host,
but has not yet opened a TCP connection.

2. CURLINFO_CONNECT_TIME is the time it takes from the start of a
transaction until the client has opened a TCP connection, but has not
yet sent its HTTP request.

3. CURLINFO_APPCONNECT_TIME is the time it takes from the start of a
transaction until the client has completed any SSL
handshaking/negotiation, but has not yet sent its HTTP request.

4. CURLINFO_APPCONNECT_TIME is 0 for any plain HTTP--as opposed to
HTTPS--transactions.

5. CURLINFO_PRETRANSFER_TIME is the time it takes from the start of a
transaction until the client has finished sending its HTTP request,
but has not yet received the first byte of the response.

6. CURLINFO_STARTTRANSFER_TIME is the time it takes from the start of
a transaction until the client has received the first byte of the
response.

7. The result of (CURLINFO_TOTAL_TIME - CURLINFO_REDIRECT_TIME) is
the time the transaction providing a non-redirect response ultimately
took.

8. The result of (CURLINFO_STARTTRANSFER_TIME -
CURLINFO_PRETRANSFER_TIME) is the time it takes for the remote host to
prepare and send at least the first byte of the response, and for the
client to receive the first byte.

9. The result of (CURLINFO_STARTTRANSFER_TIME -
CURLINFO_PRETRANSFER_TIME) is the best approximation a client can get
of latency in the server's response, but as Daniel Stenberg points out
in http://curl.haxx.se/mail/archive-2002-12/0066.html, there are a lot
of factors at play, many of which aren't under the remote host's
control.

10. If there are any HTTP redirects, the entire time that it takes for
those redirects to be processed (the loop of DNS resolved, TCP
connection opened, HTTP request transferred, and HTTP response
received) is included in CURLINFO_REDIRECT_TIME, which is added to
CURLINFO_TOTAL_TIME. All of the other times keyed to the beginning of
the transaction (NAMELOOKUP, CONNECT, APPCONNECT, PRETRANSFER,
STARTTRANSFER) are reset to 0 when all the redirects have been
followed.

I've also noticed that there's an inconsistency between the libcurl
documentation and the curl CLI client documentation:

From http://curl.haxx.se/docs/manpage.html: "time_starttransfer The
time, in seconds, it took from the start until the first byte was just
about to be transferred. This includes time_pretransfer and also the
time the server needed to calculate the result."

From http://curl.haxx.se/libcurl/c/curl_easy_getinfo.html:
"CURLINFO_STARTTRANSFER_TIME. The time it took from the start until
the first byte is received by libcurl."

If the CLI client uses the same conventions as the library, shouldn't
the man page read "time_starttransfer The time, in seconds, it took
from the start until the first byte is received"?

Thank you!

Peter
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-07-24