Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm running a Fedora 11 server with Apache 2. I'm trying to optimize so things are as fast as possible from the server side, and I'm noticing (via Firebug for Firefox) that upon loading the homepage of one of the sites on the web server that for every file it loads (HTML, CSS, JavaScript, GIF, PNG, JPG, etc.), it does a DNS lookup. All of the files it is looking up are local to the server, so I'm surprised to see it even do a DNS lookup. Also, each of these lookups is in the 150-450ms range, which is way too high for my liking.

I've tried adjusting /etc/resolve.conf to use Google's Public DNS servers. I restarted the network service and tapped the page again, but the numbers didn't go down. I've reverted back to the default DNS servers since I didn't see any gain.

Any ideas on what is causing it to: a) do the dns lookup in the first place, and b) take so long when doing the actual lookup?

Thanks in advance.

share|improve this question
    
Just to be clear, you are running firefox from your webserver? –  Zoredache Mar 17 '10 at 18:34
    
No. I am running Firefox on my machine, accessing a web site that resides on the web server. I have also had people who do not reside on my network access the site and they are seeing the same DNS Lookup issues that I'm seeing. –  Travis Mar 17 '10 at 18:42

9 Answers 9

Any call to a DNS name requires a lookup, even if it's local, so that part is expected. However, it should cache the record for as long as the TTL, so as long as you are using the name DNS name for all of your objects on the page, it shouldn't have to do the DNS lookup multiple times. You don't happen to be using unique cnames for each object on the page?

Check the TTL setting for your zone to confirm that it's set to something reasonable.

As for the longer times, it could be from either the DNS server or the DNS client. Try testing using nslookup to do DNS queries directly against the DNS server to see if you get the same response time. You may want to walk the domain name path from the TLD down to your domain name (or cnames) to see where it slows down.

A way to rule out (or in) your DNS client is to watch a public site like google.com with firebug to see if it is also slow.

share|improve this answer
    
I ran dig (on the domain in question) in 2 locations: directly on the web server, and on my machine (mac). Both query times were in the 0-1ms range, but I did come across something interesting. On the web server, it displayed an authority section, and additional section: ;; AUTHORITY SECTION: com. 87426 IN NS B.GTLD-SERVERS.NET. com. 87426 IN NS L.GTLD-SERVERS.NET. etc. I did not receive the authority section when querying with my Mac. Also, I did check some other sites that I knew weren't using CDNs and they didn't have the DNS issues I'm having. –  Travis Mar 17 '10 at 18:55
    
To answer your other questions: I'm not referring to any other CNAMES, I'm using absolute paths in the HTML to refer to the files in question; The TTL is set to 86400 –  Travis Mar 17 '10 at 19:10
    
The authority section is probably fine. Your web server must have DNS installed on it. If DNS queries are slow from outside the server then it sounds like it's not related to the server itself. You've narrowed it down to a DNS issue. You mentioned a CDN. Are you using a CDN's DNS? If so, is that different than the 0-1ms range results you got from testing the domain? A CDN is going to have some unique DNS settings that will attempt to have minimal or no DNS caching. Have you tested all DNS records for the CDN? –  Scott Forsyth - MVP Mar 17 '10 at 19:15
    
I mentioned CDNs because I wanted to test sites that were similar to mine, in that they didn't have CDNs. The server is a cloud server with Rackspace. Could it be something relative to cloud hosting? –  Travis Mar 17 '10 at 19:34
    
Your description seemed like a DNS issue. Just to confirm, in firebug you can tell that it's the DNS lookup for the objects that is taking 150-450ms? What I don't understand is why that report shows the high numbers but your direct DNS test is 0-1ms. Are you sure that the "dns lookup" is the issue, or is it downloading each of the objects? If it's truly DNS relaed, then the cloud shouldn't come into play, but if it's object related then the cloud may be a factor. Try to narrow down the issue into the small part possible. i.e. can you view a single image by itself and repro? –  Scott Forsyth - MVP Mar 18 '10 at 1:39

I had a very similar problem and solved it. It was a problem with our iptables configuration, which I understand was custom in-house, so you probably don't have the same problem but I thought I would link it up just incase.

http://serverfault.com/questions/146052/only-receiving-one-document-at-a-time-from-new-web-server/147567#147567

"Removing -m limit --limit 1/s from our iptables configuraton solved the problem presented."

share|improve this answer

I've just been troubleshooting this exact problem with one of our servers - multiple DNS lookups per page showing up in firebug, one for each item that gets loaded. We've found that the issue was that in the Apache config, KeepAlive was set to Off. Changing this to "On" enabled multiple requests to be made per TCP connection and prevented the DNS lookups for each item.

We've found loading times are now half to a third what they used to be, and the DNS requests aren't showing up in firebug anymore.

More info:

http://httpd.apache.org/docs/current/mod/core.html#keepalive

share|improve this answer

Are you logging the domain name, or doing some other reverse DNS lookup for the users' IP addresses?

It's also often a problem, when you're using domain names instead of IP addresses somewhere in your apache config files.

share|improve this answer
    
No. HostnameLookups is set to Off and looking through both the access log and combined logs, they are only logging IPs. –  Travis Mar 17 '10 at 18:41

what are your ping times to your dns servers? If you've got high latency to your dns servers then you will get high latency dns lookups. If your dns servers are overloaded, think about adding a caching name server to you network, this will improve performance.

Your gateway can also be configured to give dns traffic higher priority, thus keeping looks up fast.

I've never used a windows dns server before, but maybe you can explore the unix route. Low latency, high concurrency servers are what unix really is good at.

share|improve this answer
    
I pinged the following 4 servers (may be just 2 servers, can't tell): the 2 IPs in my resolve.conf (0ms ping) and the 2 nameservers for the domain in question (0ms). Seems like it has to be something system-based... –  Travis Mar 18 '10 at 13:09

Check the paths you're using for your content. Do you have absolute or relative paths used, and are you using an fqdn for content?

Example:

<img src="http://mysite.mydomain.com/mypic.png" />

instead of:

<img src="mypic.png" />

Depending on your flavour of DNS, and other factors, the fully qualified domain name might trigger a DNS lookup every time.

share|improve this answer
    
The site in question was built using WordPress, and WP sets variables for use within your layouts to refer to files within your "template directory", "stylesheet directory" etc.. Those variables, by default, have the FQDN built in. I have adjusted those variables and I am now using path based sources (i.e. /images/blah.png). There have been no changes in the DNS times by making that adjustment. –  Travis Mar 18 '10 at 13:32
    
Any chance that the setting is cached and hasn't taken effect yet? If they were absolute URLs previously, that sounds like a good lead why DNS is used on each request. If you view-source on the webpage, are the URLs relative or absolute? –  Scott Forsyth - MVP Mar 19 '10 at 4:17
    
The URLs are relative now. The changes took effect immediately after adjusting the script and I have turned caching off on my browser when testing everything, to ensure I am accessing it as a user would when they first visit the site. A note on the caching: I've visited other sites with the same "no-cache" settings and it has not done a DNS lookup for every file, so I know that setting on my browser is not causing the multiple DNS lookups. –  Travis Mar 19 '10 at 15:15

Could this be caused by the Keep-Alive issue described here: http://linuxmafia.com/pipermail/sf-lug/2010q2/007698.html ??

For some background see the section 14.10 here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html and also (especially section 8.1.2) here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

Basically HTTP version 1.1 by default uses persistent connections. I had the same issue as you and it turns out that my local web server forces the browser to close the connection (issues "Connection: close" header in response).

share|improve this answer

This sounds more like a client issue than a server issue. The server almost certainly isn't doing DNS lookups - it's whatever client you're using to connect to it. If I'm wrong on that point, you should definitely clarify that, because the post reads as if it's the server doing the looking up, and that would simply be creepy. :)

Guess: Your client browser is configured for automatic detection, and your WPAD.dat / PAC file uses a method that requires DNS resolution - something like IsInNet, DnsResolve, or similar.

This might be combined with a disabled DNS cache on the client.

On Windows, IE used to have a built-in DNS cache, but I think that's subsequently gone away in favour of using the Windows DNS Client (dnscache) service. No idea about other browsers or platforms. (Have you tried other browsers?)

So, my $0.02: turn off all proxy settings, and see what you get. Or turn on an explicit proxy and off autodetection, and the proxy becomes responsible for all name resolution. Fun!

share|improve this answer

I'm seeing the same behavior in firebug for an external site that I'm analyzing. AFAICT, there's nothing wrong with the DNS server - dig shows a completely reasonable TTL. But for some reason, FF is taking hundreds of ms to do the DNS lookup portion of a request. Maybe a bug in firebug?

share|improve this answer
    
Hmm! The site I'm looking at has many images, and it looks like the DNS lookup times get longer in chunks of 6 images requests - I know the FF will only open a certain number of connections to a web server. I wonder if the time FF spends waiting for existing connections to close is logged as "DNS Lookup" by firebug? –  Firebus Dec 1 '10 at 1:42
1  
Hi Firebus, and welcome to Server Fault. Please keep in mind that this is not a forum, and "me too" posts don't belong in the answer section. If you have an ANSWER, then feel free to put it in the answer section. Otherwise, please use the "add comment" feature to add a comment to the original question or some other answer. Following these basic rules will help to keep Server Fault a great place to find answers to complex questions. Thanks! –  Jed Daniels Dec 1 '10 at 2:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.