[sf-lug] multiple dns lookups for one page?

[Andrew E]

Wow, good call. That would make sense that it's a constant TCP connection
rather than DNS and Firebug is just assuming that it's DNS. I think this
excerpt agrees with your hypothesis:

Their example that is in httpd.conf (I think?):

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 2

*By default, KeepAlive is turned off. By turning it on (KeepAlive On), we
allow a single TCP connection to make multiple requests without dropping the
connection. For Drupal this is important, since each page typically has
several elements on it, and a single hit on that page might make multiple
requests. If KeepAlive is off, each element request will result in a new TCP
connection and its associated overhead. The total number of requests
available per connection is set by MaxKeepAliveRequests, here set to 100.
The total amount of seconds the connection will stay up is set by
KeepAliveTimeout, and I've set it to twice the length of my longest average
page request.*


I'm looking into the best way to handle this keep-alive issue, but I'm all
ears if there is a best practices for this.

Thanks,

Andrew


On Thu, Apr 15, 2010 at 12:12 PM, Nathan Hoover <nathan at foo-o-rama.com>wrote:

> I think I have something here, although I am still not sure why Firefox is
> taking so long to do what should be a local (in-process to FF) cache lookup
> for DNS.
>
> I compared the HTTP headers from my site that's behaving more sensibly to
> the site you mentioned, and I noticed in all the subsequent requests that
> are doing an additional DNS lookup, the "Connection:" HTTP header is being
> set to "close" rather than "keep-alive" - thus initiating a new TCP
> connection, an expensive prospect DNS lookup or no. (In fact, as I write
> this, it might be that Firebug incorrectly reports some of the connection
> overhead time as DNS lookup even if no actual lookup is being done).
> Certainly, on my system, a remote lookup (even on our corporate DNS system)
> didn't happen - I observed the whole network stream with Wireshark.
>
> I hope this helps!
>
> Nathan
>
>
> On Thu, Apr 15, 2010 at 11:52 AM, Nathan Hoover <nathan at foo-o-rama.com>wrote:
>
>> Interestingly, I am seeing the same behavior on my machine. My first
>> inclination was that Firebug was erroneously reporting DNS lookup time, but
>> I discounted that quickly by looking at one of my own sites, and not
>> observing a similar pattern. My next inclination was that it was a DNS
>> configuration problem (ridiculously low TTL?) but a quick look doesn't seem
>> to bear that out either. Now my curiosity is piqued! If I find anything,
>> I'll let everyone know.
>>
>> Nathan
>>
>>
>> On Thu, Apr 15, 2010 at 11:18 AM, Rick Moen <rick at linuxmafia.com> wrote:
>>
>>> Quoting Andrew E (andrewevansc at gmail.com):
>>>
>>> > CONFIDENTIAL:
>>>
>>> [RM: snip server URL and related text, which I'm pretty sure were the
>>> only confidential parts]
>>>
>>> > Firebug shows me a whole bunch of DNS lookups. Does it look like that
>>> IPv6
>>> > vs IPv4 issue? I'm unfamiliar with how to diagnose issues with these
>>> > protocols or DNS in general. Here is a phpinfo() about the server
>>> > http://native-instinct.com/portfolio/info.php if that helps.
>>>
>>> As Nathan said, and I was implying, Firebug is reporting what's going on
>>> at the machine where _Firebug_ is running, which is where your Web
>>> browser is -- which Web browser I believe would be Firefox, right?
>>>
>>> So, the real question you should be asking yourself is, where's your
>>> Web-browsing machine (the machine you're running your -browser- on)
>>> consulting for DNS?  Is the Web-browsing machine attempting IPv6-enabled
>>> DNS and falling back to IPv4-based queries when those fail?
>>>
>>> One quick way to check is to install Unbound, an IP6-enabled open-source
>>> recursive nameserver available for Unixes (including Linux and OS X) and
>>> MS-Windows, pointing your machine at it for nameservice, and seeing if
>>> the problem goes away.
>>>
>>> The URL I posted earlier details how.
>>>
>>>
>>> _______________________________________________
>>> sf-lug mailing list
>>> sf-lug at linuxmafia.com
>>> http://linuxmafia.com/mailman/listinfo/sf-lug
>>> Information about SF-LUG is at http://www.sf-lug.org/
>>>
>>
>>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20100415/8b036fa9/attachment.html>