OK so I’m on a big kick to get the fastest site possible, I’ve run many, many tests here. I recently moved my site that gets 600K+ unique visitors/month onto a SSD VPS and it is faster and I’m happy.
Here’s the thing… DNS. Right now I’m using the default DNS nameserver records which simply point to my VPS server. I know that’s slower than using a service like DNSMadeEasy. I am still a customer of DNSMadeEasy but I don’t use them anymore. I’ve decided I want to use them again, I just want speed, speed, speed.
So here’s the deal. Everyone visiting the site from either example.com or www.example.com gets redirected to the www. version of my site (www.example.com), I use the following entry in the root .htaccess to do that:
rewriteCond %{HTTP_HOST} ^example.com [NC]
rewriteRule (.*) http://www.example.com/$1 [R=301,L]
Now, I’m setting up my DNS records at DNSMadeEasy, and I kind of understand it. I’ve setup an A record to the IP address of the web server for example.com. So that’s good.
Now here’s the thing. For the www. DNS record should it be an A or CNAME record? I’ve heard conflicting reports, some people say if I use a CNAME record it means one extra lookup (thus, slightly slower response times), so to use an A record. Another guy said it doesn’t matter if you’re on the same name server, there is no extra lookup.
For convenience I’d rather just set a CNAME for www. so it’s one less place to update the IP address if I ever move in the future, but it really doesn’t matter to me.
What is faster? Set www. a CNAME or A name? I only care about speed.
Thanks.
p.s. While I’m at it, is that .htaccess entry the fastest way to get the job done (redirect non-www visitors)?
Whenever you can, you should move your rewrite rules from .htaccess files to your Apache configuration file (httpd.conf), then preferably turn off .htaccess functionality altogether (using AllowOverride None) so Apache won’t look for it in every directory.
Thanks. So it looks like I should use ANAME instead of CNAME since DNSME supports it, and it will be the fastest. OK, I can do that.
I am wondering though can I just create an A record of www.example.com. and it does the same thing, effectively? It doesn’t matter too much as I’ll just setup ANAME instead of CNAME.
I will look into that httpd.conf thing, I’ve heard of that before but never looked into it. Being a VPS I have basically full control to do things like that. Unfortunately I believe I will need to keep .htaccess functionality turned on to support various scripts (photo gallery/forum).
As I dig more into the httpd.conf thing I may have more questions, but I’ll start a new topic for that. Thanks.
[hr]
Well I had contacted DNSME support earlier, this is their reply:
[quote]ANAME records will be faster if the target is outside of the current domain name. A CNAME record to another host in the same domain will be just as fast as an ANAME record.
If the IP address of your web server does not regularly change, then you would be even better off just creating an A record for www that points to the IP address of your web server - just like you did for the ftp and mail records.[/quote]
So in the end I’m just going to use an A record for the www. record since my IP won’t change for years.
As long as you copy the rules from the .htaccess files used or created by those scripts into the right location of your Apache configuration file, they will work just the same with .htaccess support turned off. Whenever they need to make changes, however, you’ll have to manually edit the httpd.conf file again and reload the configuration (you don’t have to restart Apache after a change, reloading is better). Run ‘configtest’ before you commit any changes. You’ll want to be careful, of course, when making changes to Apache on a production server with that many users, but there are plenty of tutorials to guide you through editing httpd.conf safely.
Thanks for sharing that reply from DNS Made Easy. Clears things up a bit for me, too.
Although I don’t have a definite answer for this, but I’ve seen a few huge sites using A records for WWW.
As for DNS, I’ve used DNSMadeEasy before and it was causing random spikes in time to download for Googlebot shown in Webmaster Tools. I’ve later switched to Dyn Enterprise and then now to EdgeCast Route, no more spikes.
Amazon Route is fast as well, but every week there will be one day with higher crawl time.
Well I thought I’d post a follow-up. I did just use an A record for www. with DNSME, and I’m live on that now. So far so good, I think the difference is negligible but it’s hard to say without doing multiple tests from various locations across the country/world. Regardless, sending DNS queries out to DNSME should ever so slightly decrease the load on my VPS which is good.
I’ll keep an eye on WMT to see if they notice any differences. The other sites that I moved to the SSD VPS have shown it takes less time to download files (crawl) so moving to SSD seems to have been a very worthwhile decision.
I’ll post a new thread if I need help with that httpd.conf / htaccess thing to try and keep this on topic. I’ve got to get some of my other sites all moved over to the new SSD VPS before I have time to look into the httpd stuff anyway.
That, and they have a global unicast network of DNS servers, so the latency of lookups should certainly improve.
Returning to the original question, the conclusion is that an A record is just as fast as a CNAME record when they’re within the same domain, e.g. CNAME www.(example.com) points to A record (example.com), while a CNAME of cdn.example.com that points to a different domain like yoursite.cloudfront.net would incur an extra lookup and thus be slower.
Good luck with the other tweaks. Full speed ahead
As for the graphs in Webmaster Tools, I wouldn’t put much stock in them. Trends may be interesting if you can spot them, but individual spikes are pretty meaningless without further details. Only real user data can tell you how fast your site (and DNS) is.
TBH if using an SSD speeds up file downloads, then I’d start looking at what and how your web server is caching.
In theory, a web server well fed with memory will be caching all necessary files, so only the initial request should be slower when using spinning rust.
As for DNS, it’s important that your master server is close to your intended client base, and that you’ve got a decent length TTL set. But as it’s a distributed system, it’s completely out of your hands, and will be pretty instant once the client’s local DNS server is primed.
Well I’ve tweaked many things within my control, and I’m still not happy with my performance, specifically the time to start render. I think it’s due to running ads on the page. Here’s an example, see how fast the origin files load (< 0.5 sec), and then the page doesn’t start rendering until 0.9 sec, sometimes 1.2 sec. Frustrating, I need the ads to pay the bills.
[link]
I may not be using caching the ideal way. I’m just using a simple script that caches the dynamic pages in html files and checks if it’s been an hour since the file was last generated. Honestly at this point I think I’m at the point of diminishing returns. I want the page to start render in < 0.5 sec but in the big picture the site really isn’t that bad.
I’d look at reducing the number of files - combine all the .js would be a good starting point. Another approach would be maybe to look at using mod_pagespeed backed by memcached ( I don’t think redis is available yet ) to improve your sites performance… it can post process the output as well as cache stuff.
I’d also look at reducing the external services in use, as you just can’t control their performance!
Yeah well I only have 2 js files. I used to use Addthis, it was total bloat, I now use share42 (light local script). I discovered that my Vibrant Media ads are making 34 requests and not making a whole lot of cash, so they will probably go away soon… although I don’t think that has anything to do with the render start time. Now that I think about it I could use some image sprites. Anywho, I’ll post a new topic for other topics just so we can keep this one on-topic.
