cURL / Mailing Lists / curl-library / Single Mail


[ curl-Bugs-1145042 ] Incorrect results returned in time_namelookup?

From: <>
Date: Sun, 20 Feb 2005 13:35:36 -0800

Bugs item #1145042, was opened at 2005-02-20 16:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:

Category: http
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 5
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


You can respond by visiting:
Received on 2005-02-20