Akamai 与较小的 CDN 用于中小型电子商务流量？（缓存、延迟、NetStorage）

Question

我工作的中小型在线零售公司使用 Akamai 作为我们的静态图像 CDN，但我想知道它是否可能会造成伤害而不是帮助，如果它不是最理想的，我们应该怎么做。

我们每月获得大约 300 万次浏览量和 40 万独立访问者。我们有 100k+ 不同的静态图像出现在我们的各种网页中（数千种产品中的每一种都有几个不同的图像等）。

问题是 Akamai 的服务器从源服务器（我们自己托管）请求文件，以处理大约 40% 的浏览器请求。这意味着很多（在我看来）我们的客户没有必要等待：40% 的请求必须在返回给客户之前在 Akamai 和我们的原点之间进行往返。

服务器 TTL 不是问题；它们都设置为 365 天。所以它似乎要么

1. Akamai 的边缘服务器没有将我们的内容在缓存中保留足够长的时间，然后才将其替换为流量高于我们的内容，和/或
2. 有太多 Akamai 边缘服务器（他们声称在全球拥有 7 万多台），以至于每个服务器都无法从我们每月 45 万的访问者那里获得足够的流量来建立我们文件的大部分缓存。

所以我开始怀疑是否可以通过服务器较少的 CDN 为我们提供更好的服务，我的想法是使用较少的 CDN 服务器，我们的更多图像将更频繁地缓存在每个服务器上，并且可能会在缓存中停留更长时间不被换出。另一方面，对于不靠近其中一台服务器的用户来说，更少的服务器可能意味着更多的延迟。

我们正在查看两个基于 Akamai 的选项，但（还）尚未启动：

• 我们还没有使用他们的 NetStorage 服务，因为有一个技术障碍（如果我们朝那个方向前进，这将是我下一个 SF 问题的主题）并且因为 40% 的时间之间仍然会有额外的往返边缘服务器和源；它只是在 Akamai 网络内的往返，而不是到我们单独托管的来源——可能更快，但仍然是往返。
• 我们不为 Akamai 的可选分层分发服务付费。这可能会在很大程度上缓解问题，但是 (1) 它并不便宜，并且 (2) 同样，40% 的时间在边缘服务器与其层集线器之间仍然存在往返。

所以我的问题是：

1. 你们是否都认为将文件缓存在更少的服务器上会更好，但代价是某些用户的额外延迟；或者延迟是不是比原点往返更大的问题？

2. 如果我们使用 NetStorage，有没有人知道往返 NetStorage“原点”通常需要多长时间？

3. 我错过了什么吗？我还应该在这里考虑什么？

Answer 1

基于事实而不是假设总是更好。您的假设是，节点较少的 CDN 访问您的源站的频率会较低。为了测试这一点，我会：

1. 在多个进行原始提取但具有“超级 POP”模型的 CDN 上设置一个帐户。我想到的是 Amazon CloudFront、MaxCDN 和 Voxel。CacheFly 也许也是如此，尽管我认为如果没有服务参与就无法进行原始获取。LimeLight首创“超级POP”模式，但需要通过销售歌舞来设置考验。
2. 将 CDN 流量中具有统计意义的部分转移到这些测试 CDN。这可能就像在 n% 的时间内执行重写规则一样简单，但所有 CDN 的“内容组合”需要完全相同。您不能将其限制为静态资产的子集，因为静态资产的数量也可能产生影响。也许在 Akamai 上保留 80% 的流量进行测试，然后为其他 CDN 保留 5%。
3. 使用您的网络服务器日志来衡量您从每个 CDN 看到的源点击数与发送到每个 CDN 的流量。
4. 使用 pingdom 之类的工具来测量每个 CDN 上各种静态资产的全球响应时间。从来源卸载点击量是 CDN 发挥其作用的指标之一，但最终用户延迟也很重要。

掌握了这些事实，您的决定就会很容易。就其价值而言，我实际上认为您是对的：Akamai 可能为“较小”站点提供了太多节点。

请注意，一些较小的 CDN 会自动对所有内容使用分层模型；它们从一开始就是这样构建的。在这样的模型中，对特定边缘节点的请求在高速缓存未命中时被路由到“内部”节点。如果“内部”节点也有缓存未命中，则它会路由到原点。我自己的测试表明 MaxCDN 是这样工作的（例如，在阿姆斯特丹节点上对文件的第一个请求并不总是导致相应的原始获取。因此它一定是从 MaxCDN 网络内的其他地方获取了文件）。