Latency vs. Geolocation: Testing DNS configurations across multiple EC2 regions using AWS Route 53
If you’re using the AWS stack, you’ve probably been through this: Deciding which EC2 instance to fire up and which region to deploy them on is tricky. Some of you might have started multiple EC2 instances behind a load balancer – but that’s almost never enough. Our Aussie friends shouldn’t have to wait for resources coming from Virginia. What we really need is an easy to use global solution.
This is where Amazon’s Route 53 DNS routing comes in handy. Adding routing policies to your domain will help guarantee that users get the fastest responses, and as we all know, speed == happiness.
At the end of July 2014, Amazon announced a new Route 53 routing policy: Geolocation. We are big advocates of latency-based routing so we wanted to put the new policy to the test.
Results
Since this benchmark’s goal is to make sense of DNS, we looked at the DNS name lookup time. We used curl to get a breakdown of how long each step lasted. Here are the average lookup times from EC2 regions:
Full results can be found here.
Insights
- The tests show that switching to geolocation adds 75ms on average – a very high figure, especially if you’re trying to optimize your cluster and first user experience.
- If we exclude Sao Paulo from the list altogether we get an impressive 127 ms average lookup time across other regions for both policies. I checked the numbers twice to make sure it’s not a mirage. Exactly 1 2 7 ms whether you go with geolocation or latency. On our EC2->S3 benchmark it was Sydney that was kicked out, with Route 53 it’s Sao Paulo.
- The biggest winner is Europe. It had the lowest latency-based lookup, the lowest geolocation-based lookup and the lowest difference between latency and geolocation – only 3 ms!
- At the bottom of the list – Sao Paulo performed the worst. It came in last in all three criteria: latency, geolocation and difference. Geolocation lookup in South America took 3x times more than the latency lookup.
- Zooming into North America, the fastest name lookup in both latency and geolocation was California. The slowest one was Virginia, which had the second biggest difference between latency and geolocation. Geolocation in our tests was around 1.5x times slower.
- Geolocation was faster in Oregon, California and Singapore. Latency was faster in Virginia, Europe, Japan and Brazil.
Setting up the test
EC2 – We deployed a simple Tomcat/Nginx web application into EC2 instances (m3.medium) on all AWS regions available (excluding China’s beta region). The webapp contained several Java Servlets that returned HTTP_OK 200 upon request.
Route 53 – We purchased two domains beforehand. One for latency and one for geolocation. AWS has great docs on how to setup the record sets for latency-based and geolocation-based routing. For the latency-based we redirected the domain to all regions where we have EC2 running. For geolocation we redirected each continent to the closest region.
Bash – After setting up all instances, we ran this snippet to test for lookup time for the domains. We decided to look at lookup times alone, since the connect time shown by curl was ~1ms and didn’t change the results.
sudo /etc/init.d/nscd restart ## Restarting the DNS on Ubuntu so we won’t have cache
curl –no-sessionid -s -w ‘\nLookup time:\t%{time_namelookup}\n’ -o /dev/null http://takipi-route53-testing-{latency|geo}.com/webapp/speed/normal ## Measuring name lookup time
Conclusion
There was no knock-out winner here. Although latency-based routing proved to be faster, there were some cases where geolocation-based routing performed better. The fastest average lookup was latency-based originating from Europe. In the end, unless you require some country-specific routing, DNS routing policy’s sweet spot is (still) latency-based routing.
| Reference: | Route 53 Benchmark: The New AWS Geolocation’s Surprising Results from our JCG partner Chen Harel at the Takipi blog. |
