延迟与地理位置:使用AWS Route 53在多个EC2区域中测试DNS配置
如果您使用的是AWS堆栈,那么您可能已经经历了这一过程:确定要启动哪个EC2实例以及在哪个实例上部署它们是很棘手的。 你们中的某些人可能已经在负载均衡器后面启动了多个EC2实例-但这几乎是远远不够的。 我们的澳大利亚朋友不必等待来自弗吉尼亚州的资源。 我们真正需要的是一个易于使用的全局解决方案。
这是亚马逊的Route 53 DNS路由派上用场的地方。 向您的域添加路由策略将有助于确保用户获得最快的响应,众所周知,速度==幸福。
2014年7月底,亚马逊宣布了一项新的Route 53路由策略:地理位置。 我们是基于延迟的路由的拥护者,因此我们想对新策略进行测试。
由于此基准测试的目的是使DNS有意义,因此我们研究了DNS名称查找时间。 我们使用curl来了解每个步骤持续了多长时间。 以下是来自EC2区域的平均查找时间:
完整的结果可以在这里找到。
见解
- 测试表明,切换到地理位置平均会增加75毫秒-很高的数字,尤其是在您要优化集群和首次用户体验的情况下。
- 如果我们将圣保罗排除在外,则这两个策略在其他地区的平均查询时间为127 ms。 我检查了两次以确保它不是海市rage楼。 无论是地理位置定位还是延迟,都精确到1 2 7毫秒。 在我们的EC2-> S3基准测试中 ,悉尼被开除,而Route 53是圣保罗。
- 最大的赢家是欧洲。 它具有最低的基于延迟的查找,最低的基于地理位置的查找以及最低的延迟与地理位置之间的差异–仅3毫秒!
- 在榜单的底部-圣保罗表现最差。 它在所有三个条件中都排在最后:延迟,地理位置和差异。 南美的地理位置查找所花费的时间比延迟查找所花费的时间多3倍。
- 放大到北美,在延迟和地理位置上最快的名字查找是加利福尼亚。 最慢的是弗吉尼亚州,在延迟和地理位置之间的差异第二大。 我们的测试中的地理位置降低了约1.5倍。
- 俄勒冈州,加利福尼亚州和新加坡的地理位置定位速度更快。 在弗吉尼亚州,欧洲,日本和巴西,延迟时间更快。
设置测试
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路由策略的最有效点就是(仍然)基于延迟的路由。