I'm not sure when I started seeing this, but I seem to resolve bugzilla.mozilla.org a lot more than I used to, and it seems slower to load because of this. did we just add status message for resolving hostname? I know we used to have a DNS cache, did it get disabled?

I use Windows 98 and Mozilla 0.8.1 and while browsing, the browser show very long time status text "Resolving host x" before starting do render the page. After using tcpdump I found that browser gets the dns-information very quick, but doesn't change the text to "Waiting for x" etc that it should be as it just stays waiting for remote host for data...

-->darin

i think this is a known docshell problem. over to rpotts.

-> gordon. how can dns resolution be dns docshell related?

-> darin

ugh. long day. -> gordon

1. DNS status messages have always been there, just that they have started being visible with cleanup in docshell/status reporting area. 2. Most OSs that we care about already do a fairly usable amount of DNS caching. Unless you are running a number of applications that are extensively using that cache (and flushing things out of it) this suffices. I spent some time tracking the lookups under ngrep (network sniffing tool) and noticed absolutely insignificant times for subsequent DNS lookups. 3. The "delay" that we see is not really becuz we are spending more time in DNS lookups (as is also evident from Pauli's comments) but its becuz subsequent updates of progress do not get reflected right away on status bar. The progress notifications and the stream listener notifications are all sent thru events and often no visible activity occurs till the layout/parser finishes its update. This is essentially the same issue that hyatt discovered with large (time consuming) layout events. (Anyone remember the bug number?) When they do get a chance the "contacting-host" message is almost immediately followed by the actual receiving of data and hence the state that shows up for most duration on the status bar is the "resolving host" So I think there is no need to do a DNS cache till at least we determine that its a long pole in the page loading process. If you still suspect DNS to be taking a long time, try out a build with DNS_TIMING defined and see for yourself.

> Most OSs that we care about already do a fairly usable amount of DNS caching. Could you provide some supporting evidence for this? The two pieces of documentation I could find on Windows: http://support.microsoft.com/support/kb/articles/Q245/4/37.ASP http://msdn.microsoft.com/library/psdk/network/dns_api1_2ant.htm both discuss DNS caching services only available on Windows 2000. > absolutely insignificant times for subsequent DNS lookups. Did you do this over a fast network or a modem? My anecdotal experience over a modem is that when the link between you and a caching DNS server is slow, this latency is quite significant. > subsequent updates of progress do not get reflected right away on status bar. Ok, then let's fix that, and then we'll see where we are.

For Mac- read the last paragraph on this link-- http://developer.apple.com/techpubs/mac/NetworkingOT/NetworkingWOT-54.html and for Linux the kernel does some minimal caching-- I didn't spend too much time searching for that article ... but I could if you don't believe me. In general most DNS servers do caching already. So even if we are on an dumber-os that doesn't cache dns lookups the server that its connecting to would most likely be caching the lookups. Even though my tests were on fast network, I am not convinced that the lookup times are very significant. In essense a lookup is just another connection on port 53 with the actual amount of information being almost always less than a packet. Phil: I would strongly suggest you try a nslookup (or even a ping on windows) to see how soon an address is resolved when you are next connected via modem. Note the time to see "Pinging foo[ipaddress]" and not the actual ping times. Try that again within a few seconds and you'd see that the resolution is almost instantaneous. The steps it goes thru and the time it takes to resolve would be fairly similar to our contribution in the page load time. And I agree that we do have a bug to fix with the status messages not getting updated right away. So lets focus on that first.

I'll wait for the status bar issue gets fixed (bug#?) before complaining any more about client-side caching. > In general most DNS servers do caching already. Yes, but if the connection between the client and the caching DNS server is slow (e.g. over a modem) this doesn't help. We should be able to to Back to cached page very quickly, but due to apparent DNS resolution, we require a network round trip. Try it over a modem -- you'll see.

We already have a bug to implement DNS caching; it's bug 30917. Should we use this bug to fix the status display (and assign it to someone else) or is there already a bug for that? If a bug already exists for fixing the status display, then we should dup this one to that or bug 30917.

-> Gagan for bug administration.

qa to me. Phil, re: modem example if a system has long DNS latency and an OS cache, an application DNS cache will not help performance. re: load page;cache page;go "back";see delay In my mind, going back shouldn't fire off DNS requests, this is reported in bug 75134.

> if a system has long DNS latency and an OS cache, an application DNS cache will > not help performance. So far, no evidence has been provided than Windows (other than Win2k) has a DNS cache.

OK so I investigated this a little further. We are doing DNS resolutions with each call that requires address resolution. You won't see it on regular page loads since the requests queue up but for reloads and for back/forward (with specific cache cases) we do the resolution all over again. And what I confirmed that depending upon the RTT to the DNS server this can affect us pretty significantly. So Phil you are right- we need to fix this! I am going to go ahead and mark this as a dup for bug 30917 *** This bug has been marked as a duplicate of 30917 ***

verified dup