我正在通过 CloudFront 提供软件下载服务。北美的丢失率远高于欧洲。美国的丢失率为 55.7%，而欧洲的丢失率为 19.69%。
北美：
欧洲：
CloudFront 配置为“最佳性能”。文件存储在俄亥俄地区的 S3 存储桶中。
为什么这两个地区的错误率有如此大的差异？
答案1
该问题似乎与北美相比接入点数量较多且请求较少有关。
看来我们正面临 CDN 挑战：缓存空间的竞争。我们的文件非常大（例如，它们占用的缓存空间比图像还多）。可能是因为北美每个接入点的请求率不够高，无法将其保留在 CloudFront 的缓存中，所以我们的内容没有保留在缓存中。
两天前我们换了一家北美接入点更少的供应商。这两天的累计统计数据显示，我们的错误率现在只有 11%。因此问题解决了。
更新：
命中率/未命中率比例似乎不能说明 CDN 性能的全部情况。我配置了 4 个 CDN 提供商：CloudFront、Google CDN、Fastly、BunnyCDN + 将 Google Storage 纳入测试。所有 CDN 都配置为使用尽可能多的 POP 服务器。Google Storage 在美国处于多区域模式。
然后，我配置了 Uptrends 和 Pingdom，每 5 分钟下载一个测试文件。我们提供软件下载服务，该配置与我们看到的现实世界负载大致相似 - 每隔一分钟左右就会收到来自世界各地的下载请求。这样的负载使 CDN 不那么有效，因为文件往往会在 CDN 边缘节点上过期。
Uptrends 允许我们选择测试地点，我选择了以下所有城市：北美、澳大利亚、新西兰、德国、法国、西班牙、意大利、波兰和俄罗斯。Pingdom 不允许更改检查点位置，并提供欧洲和美国的随机位置。不幸的是，Pingdom 没有包括澳大利亚检查点。
测试文件大小为 43 Mb。我在所有提供商上进行了大约 20 小时的测试。测试结果如下：
平均下载时间 - 上升趋势（越小越好）：
下载性能 - Pingdom（越小越好）：
有趣的是，在两个测试平台上，普通的 Gloud Storage 都比 Google CDN 快。这可能是我的配置错误，也可能是 Google CDN 不会在其节点上长时间保存大文件。
Uptrends 上出现了下载超时。如果服务器在 45 秒内无法下载文件，就会发生超时。在 20 小时内，CloudFront 有 2 次超时，Google Storage 有 4 次超时，Google CDN 有 8 次超时，BunnyCDN 有 6 次超时，Fastly 有 6 次超时。