关于区域间延迟的问题
【以下的问题经过翻译处理】 根据concurrencylabs的博客文章< https://www.concurrencylabs.com/blog/choose-your-aws-region-wisely/>，当你将各个区域进行比较时，每个区域的延迟可能会有很大的差异。该博客作者进行了一项测试，测量了区域之间和区域内部的延迟，并将结果发布在几个矩阵表中。
以下是显示区域间和区域内部延迟结果的矩阵表链接：https://www.concurrencylabs.com/img/posts/9-choose-region-wisely/ec2-s3-1mb-table.png
所有区域内部延迟（标记为蓝色）都差别很大，俄勒冈和东京是最明显的不同值。俄勒冈是最快的，仅需81毫秒将1MB数据从EC2传输到同一区域的S3。而东京是最慢的，需要755毫秒。
此外，ping延迟的结果也很有趣，链接在这里：https://www.concurrencylabs.com/blog/choose-your-aws-region-wisely/。除了俄勒冈外，区域之间ping延迟约为3毫秒。然而，俄勒冈到俄勒冈的ping延迟高达211毫秒。
我的问题是：为什么所有这些区域在延迟方面有如此大的差异？难道每个区域的基础设施不应该具有类似的质量吗？
- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
【以下的回答经过翻译处理】 对于俄勒冈的延迟测试，我发现它相当不寻常；我刚刚对俄勒冈的不同可用区中的一些实例进行了测试，得到了我预期的时间（个位数毫秒或更短）。我怀疑在博客进行测试时可能存在一些网络异常。但是，正如一直以来的做法一样，我鼓励客户进行自己的测试，因为有很多变量——操作系统、软件版本、测试堆栈、应用程序堆栈等等。
至于1MB传输表：如果您查看这些数字，并将它们与10MB传输表进行比较，您会发现许多传输时间非常接近，尽管其中一个传输的大小是另一个的十倍。对于小包传输（1MB是一种小包传输），其中有相当一部分时间用于协商TLS会话，S3也需要处理正在上传的文件。
同样，在这个特定的基准测试中会有差异——远远大于延迟测试，因为S3是一个多租户服务。当进行测试时，您根本不知道其他操作正在进行什么，其他客户正在运行哪些操作，或者服务本身正在发生什么。因此，博客作者运行了许多测试来获得一组良好的数据。但测试最好运行几天、几周甚至几个月，以确保数据集能够代表被测试的条件。
创建这样的测试套件和数据集是一件很好的事情（特别是如果您在测试中可以得到一个与生产系统进行比较的基准），因为您可以看到性能何时改善（或下降），以及可能采取一些措施；或者至少可以获取那些数据并解释为什么您的系统可能表现出不同的方式。
回答您的最后一个问题：各个地区都是在不同的时间建立的，因此它们的建设方式会有所不同。地区始终在发生变化——主要是扩展，但也包括部署新服务以及升级现有服务（甚至您看不见的，例如网络）。每个地区都建立在不同的地理位置上——在不同城市的可用区之间不可能有相同长度的光纤传输线，而玻璃中光的速度（或者铜中电子的速度）确实会产生影响。
简而言之：如果这些数字对您很重要，请进行自己的测试；有许多，许多变量。