On Wed, 20 Jun 2018, Bernhard Jaeger wrote:

> I honestly have no Idea where this performance difference comes from as DNS
> lookup is something the operating system does and should be the same for
> both programs.

If you use a libcurl using the threaded resolver backend, I think lots of the
explanation is what sort of logic we use for the time-out based
waiting/looping we do when we resolve the host name in a background thread
without having a socket to wait for that gets triggered when the lookup is
completed.

> start doesn't necessarily mean start of the DNS lookup. Is there other stuff
> besides the DNS lookup that also is included in the measured time? (and if
> so is there a way to exclude it?)

Yes there is, but the question is if that stuff actually changes the
measurement in any significant way and no there's no way to shut that off
since that's the init stuff libcurl has to do to setup a transfer.

For the purpose of researching this, it could be an idea to set an extra
time-stamp just before the name resolve start just to see if that time ever
actually is significant.

Depending on your libcurl build, in particular on windows, it would also make
sense to check what timer resolution your libcurl gets.

> Following that I would also be
> interested to know whether: "CONNECT: CURLINFO_CONNECT_TIME and
> CURLINFO_CONNECT_TIME_T. The time it took from the start until the connect
> to the remote host (or proxy) was completed." is only the TCP handshake and

Yes

> "APPCONNECT: CURLINFO_APPCONNECT_TIME and CURLINFO_APPCONNECT_TIME_T.
>
> is only the TLS handshake (part) or if there are other things getting measured
> here.

If you're connecting to a HTTPS URL, it is post-TLS handshake, yes.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html