Route 53 Benchmark：新的AWS Geolocation令人惊讶的结果

延迟与地理位置：使用AWS Route 53在多个EC2区域中测试DNS配置

如果您使用的是AWS堆栈，那么您可能已经经历了这一过程：确定要启动哪个EC2实例以及在哪个实例上部署它们是很棘手的。 你们中的某些人可能已经在负载均衡器后面启动了多个EC2实例-但这几乎是远远不够的。 我们的澳大利亚朋友不必等待来自弗吉尼亚州的资源。 我们真正需要的是一个易于使用的全局解决方案。

这是亚马逊的Route 53 DNS路由派上用场的地方。 向您的域添加路由策略将有助于确保用户获得最快的响应，众所周知，速度==幸福。

2014年7月底，亚马逊宣布了一项新的Route 53路由策略：地理位置。 我们是基于延迟的路由的拥护者，因此我们想对新策略进行测试。

由于此基准测试的目的是使DNS有意义，因此我们研究了DNS名称查找时间。 我们使用curl来了解每个步骤持续了多长时间。 以下是来自EC2区域的平均查找时间：

完整的结果可以在这里找到。

见解

1. 测试表明，切换到地理位置平均会增加75毫秒-很高的数字，尤其是在您要优化集群和首次用户体验的情况下。
2. 如果我们将圣保罗排除在外，则这两个策略在其他地区的平均查询时间为127 ms。 我检查了两次以确保它不是海市rage楼。 无论是地理位置定位还是延迟，都精确到1 2 7毫秒。 在我们的EC2-> S3基准测试中 ，悉尼被开除，而Route 53是圣保罗。
3. 最大的赢家是欧洲。 它具有最低的基于延迟的查找，最低的基于地理位置的查找以及最低的延迟与地理位置之间的差异–仅3毫秒！
4. 在榜单的底部-圣保罗表现最差。 它在所有三个条件中都排在最后：延迟，地理位置和差异。 南美的地理位置查找所花费的时间比延迟查找所花费的时间多3倍。
5. 放大到北美，在延迟和地理位置上最快的名字查找是加利福尼亚。 最慢的是弗吉尼亚州，在延迟和地理位置之间的差异第二大。 我们的测试中的地理位置降低了约1.5倍。
6. 俄勒冈州，加利福尼亚州和新加坡的地理位置定位速度更快。 在弗吉尼亚州，欧洲，日本和巴西，延迟时间更快。

设置测试

EC2 –我们在所有可用的AWS区域（不包括中国的beta地区）上将简单的Tomcat / Nginx Web应用程序部署到EC2实例（m3.medium）中。 该Webapp包含多个Java Servlet，这些Java Servlet根据请求返回HTTP_OK 200。

路线53 –我们预先购买了两个域。 一种用于等待时间，另一种用于地理位置。 AWS拥​​有有关如何为基于延迟和基于 地理位置的路由设置记录集的出色文档。 对于基于延迟的情况，我们将域重定向到运行EC2的所有区域。 对于地理位置，我们将每个大陆重定向到最近的区域。

Bash –设置所有实例后，我们运行此代码段以测试域的查找时间。 我们决定只考虑查找时间，因为curl显示的连接时间约为1ms，并且不会改变结果。

sudo /etc/init.d/nscd restart ##在Ubuntu上重启DNS，这样我们就没有缓存了
curl –no-session id -s -w'\ n查找时间：\ t％{time_namelookup} \ n'-o / dev / null http：// takipi-route53-testing- {latency | geo} .com / webapp /速度/正常 ##测量名称查找时间

结论

这里没有淘汰赛冠军。 尽管事实证明，基于延迟的路由更快，但在某些情况下，基于地理位置的路由却表现更好。 最快的平均查找来自欧洲的基于延迟的查找。 最后，除非您需要某些特定于国家/地区的路由，否则DNS路由策略的最有效点就是（仍然）基于延迟的路由。

翻译自: https://www.javacodegeeks.com/2014/08/route-53-benchmark-the-new-aws-geolocations-surprising-results.html