performance - 使用 Cloudfront 修复 Route 53 CNAME Alias 响应时间缓慢的问题

Question

我刚刚设置了一个 CloudFront 发行版，以加快我网站图像的速度。我的图像存储在 S3 上。我已使用 CloudFront 分发端点的 CNAME 别名在 Route53 中设置自定义子域。

但是，在使用示例图像测试速度时，我发现了以下情况:

• https://s3.amazonaws.com/deseouserimages/make+a+wish.jpg 的平均加载时间为 418 毫秒
• https://cdn.lodeseo.com/make+a+wish.jpg 的平均加载时间为 97 毫秒
• https://d3fi09n8kfe0h5.cloudfront.net/make+a+wish.jpg 的平均加载时间为 57 毫秒

这 3 个 URL 指向同一个图像:

• 第一个网址是来自 S3 的原始图像
• 第二个网址是通过 Route53 中设置的 CNAME 别名访问时来自 CloudFront 分配的图像
• 第三个网址是直接来自 Cloudfront 分发的图像

测试是使用位于达拉斯的 Pingdom 完成的。我在其他地方也得到了类似的结果。

S3 的加载时间较慢是完全有道理的。图像未缓存在边缘位置。然而，仅仅通过在发行版前面使用 CNAME 就可以使加载时间几乎增加一倍，这似乎太慢了。我更愿意使用 CNAME，但不会以这种性能成本为代价。

我在这里遗漏了什么吗？我到处都读到，在大多数情况下，额外的 DNS CNAME 查找可以忽略不计。

Answer 1

一旦任何给定解析器缓存了查找 CNAME 及其目标的结果，CNAME 延迟就会消失在噪音中，但除非它是不跨越多个域的 CNAME(例如 foo.example.com)。 com.CNAME bar.example.com。)双重查找时间总是不可避免的。

但是，Route 53 不需要 CNAME 即可指向 CloudFront 分配。您可以使用 A 记录别名，它是 Route 53 的内部功能，以便在 Route 53 内部完成查找，而不是通过 CNAME 的外部引用完成。然后延迟就会消失，因为 Route 53 从其内部数据库提供答案。

在 Route 53 控制台中编辑现有 RR...将其从 CNAME 更改为 A，然后将别名设置为是。然后从别名目标选择列表中选择 CloudFront 分配并保存记录。