Bugs item #1145042, was opened at 2005-02-20 22:35
Message generated for change (Settings changed) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1145042&group_id=976

Category: http
Group: wrong behaviour
>Status: Closed
Resolution: Works For Me
Priority: 3
Submitted By: Brian McEntire (bmcent1)
Assigned to: Daniel Stenberg (bagder)
Summary: Incorrect results returned in time_namelookup?

Initial Comment:
Hello! I'm not sure this is a problem with curl, it
might be.

I'm using curl to check the response time of a web
site. (BTW, thank you, curl is a great tool!)

Inside a script, I ask curl to report %{time_total}
and %{time_namelookup}. What I've noticed is that when
time_total is high, often times, time_namelookup is
high too. This would be right if DNS lookups were slow,
but I don't think they are for two reasons:
  1) curl is running from a host behind a NAT'ing F/W
that also offers DNS caching. (Smoothwall with dnsmasq)
  2) My script checks 3 different pages on the site in
rapid succession. If the first DNS lookup is not in the
cache (though it probably is), I would expect the other
two curl connections to get quick DNS responses.

Here is a set of %{time_total} and %{time_namelookup}
from three curl calls inside the script:
 3.173 1.043
12.405 10.941
13.268 10.709

All three curl calls access the same site (same DNS
name) and just different pages. From my experience with
the site, the web site may be slow to return pages, but
then I would expect the time_namelookup to be small and
nearly constant if DNS caching is working on my site.

Could time_namelookup be returning the wrong value? If
there is anything I can do to help, please let me know!

BTW, I am running Debian Testing, here is my curl -V:

url 7.12.3 (i386-pc-linux-gnu) libcurl/7.12.3
OpenSSL/0.9.7e zlib/1.2.2 libidn/0.5.2
Protocols: ftp gopher telnet dict ldap http file https ftps
Features: IDN IPv6 Largefile NTLM SSL libz

Thanks again! -Brian

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-03-14 01:20

Message:
Logged In: YES
user_id=1110

I tested this myself now with curl 7.13.1 (but I don't think
we've done any changes in this aspect since 7.12.3)

It indicates that it works just fine:

I did:

"curl http://curl.haxx.se -w '%{time_total} and
%{time_namelookup}\n' -o /dev/null"

Multiple times. The name resolve time was rock solid at
0.052 seconds.

Then I tried the host name cool.haxx.se and the name resolve
time remained the same.

I then moved on to download a somewhat larger file from
cool.haxx.se
(http://cool.haxx.se/curl-daily/curl-7.13.2-20050313.tar.gz
to be exact)

It then showed a total time of 12.036 seconds, and the name
resolve time was still showing the very same 0.052.

I suggest you use a network analyzer and I firmly believe
you'll see that it is indeed your DNS server that is slow.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-03-03 09:58

Message:
Logged In: YES
user_id=1110

I've not had time to check this yet. I hope to find time soon.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1145042&group_id=976
_______________________________________________
http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-tracker
Received on 2005-03-16