Question

我已经尝试了很多来自Azure的CDN，并且在使用网络角色成功设置后我认为我是安全的家。

为什么是网络角色？

好吧，我想要使用普通的blob方式获得压缩和缓存标头的好处。并作为额外的奖励;区分大小写的约束也被消除了。

足够选择CDN服务 ;虽然之前的所有内容都是从同一个域提供的，但我现在或多或少地提供来自cdn.cuemon.net的所有“静态”内容。从理论上讲，这应该可以提高性能，因为与一个域相比，浏览器并行可以在“多个”域上传播内容收集。

不幸的是，这导致性能下降，我相信在提供内容之前与滚刀的数量有关（使用tracert命令）：

C:\Windows\system32>tracert -d cdn.cuemon.net

Tracing route to az162766.vo.msecnd.net [94.245.68.160]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.1.1
  2    21 ms    21 ms    21 ms  87.59.99.217
  3    30 ms    30 ms    31 ms  62.95.54.124
  4    30 ms    29 ms    29 ms  194.68.128.181
  5    30 ms    30 ms    30 ms  207.46.42.44
  6    83 ms    61 ms    59 ms  207.46.42.7
  7    65 ms    65 ms    64 ms  207.46.42.13
  8    65 ms    67 ms    74 ms  213.199.152.186
  9    65 ms    65 ms    64 ms  94.245.68.160

C:\Windows\system32>tracert cdn.cuemon.net

Tracing route to az162766.vo.msecnd.net [94.245.68.160]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.1.1
  2    21 ms    22 ms    20 ms  ge-1-1-0-1104.hlgnqu1.dk.ip.tdc.net [87.59.99.217]
  3    29 ms    30 ms    30 ms  ae1.tg4-peer1.sto.se.ip.tdc.net [62.95.54.124]
  4    30 ms    30 ms    29 ms  netnod-ix-ge-b-sth-1500.microsoft.com [194.68.128.181]
  5    45 ms    45 ms    46 ms  ge-3-0-0-0.ams-64cb-1a.ntwk.msn.net [207.46.42.10]
  6    87 ms    59 ms    59 ms  xe-3-2-0-0.fra-96cbe-1a.ntwk.msn.net [207.46.42.50]
  7    68 ms    65 ms    65 ms  xe-0-1-0-0.zrh-96cbe-1b.ntwk.msn.net [207.46.42.13]
  8    65 ms    70 ms    74 ms  10gigabitethernet5-1.zrh-xmx-edgcom-1b.ntwk.msn.net [213.199.152.186]
  9    65 ms    65 ms    65 ms  cds29.zrh9.msecn.net [94.245.68.160]

从上面的跟踪路线可以看出，所有外部内容都会延迟一段时间。值得注意的是，Azure服务是在北欧设置的，我在丹麦定居，为什么这条跟踪路线有点......嗯..超过顶部？

另一个问题可能是web角色是两个额外的小实例;我还没有找到时间尝试两个小实例，但我知道微软将额外的小实例限制在5Mb / s WAN，其中小型以上的实例为100Mb / s。

我只是不确定这是否也适用于CDN。

无论如何 - 非常感谢任何帮助和/或解释。

让我说，我对Azure平台非常满意 - 我对上述问题感到好奇。

更新

没有-d选项的新tracert。

受到 user728584 的启发，我研究并发现了这篇文章http://blogs.msdn.com/b/scicoria/archive/2011/03/11/taking-advantage-of-windows-azure-cdn-and-dynamic-pages-in-asp-net-caching-content-from-hosted-services.aspx，我将进一步研究公共缓存控制和CDN。

这并不能解释跳数过多的现象，但我希望熟练的网络专业人士可以帮助解决这个问题。

请放心，我会根据我的调查结果向您发布信息。

Answer 1

不要说明显而已，但我假设您已将Cache-Control HTTP标头设置为较大的数字，以便您的内容不会从CDN缓存中删除，并在您进行tracert测试时从Blob存储服务？< / p>

您附近有很多边缘服务器，所以我希望它能够更好地运行：'Windows Azure CDN节点位置'http://msdn.microsoft.com/en-us/library/windowsazure/gg680302.aspx

Maarten Balliauw有一篇关于CDN用法和用例的精彩文章（这可能有帮助吗？）：http://acloudyplace.com/2012/04/using-the-windows-azure-content-delivery-network/

不确定这是否有帮助，有趣......

Answer 2

好的，在我实施了公共缓存控制标头之后，CDN似乎做了预期的事情;从CDN群集中的x个节点传递内容。

上述情况受到限制 - 它没有经过具体验证的测量。

但是，此链接支持我的理论：http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_windowsazurecdn_topic3，

blob的生存时间（TTL）设置控制CDN边缘服务器在从blob存储中的源请求新副本之前返回缓存资源副本的时间。 一旦此期限到期，新请求将强制CDN服务器再次从原始blob 检索资源，此时它将再次缓存。

这是我假设的挑战; CDN引用的资源保留了原始blob池。

此外，还必须给予此链接信用（由user728584给出）; http://blogs.msdn.com/b/scicoria/archive/2011/03/11/taking-advantage-of-windows-azure-cdn-and-dynamic-pages-in-asp-net-caching-content-from-hosted-services.aspx

现在的最后一个链接：http://blogs.msdn.com/b/windowsazure/archive/2011/03/18/best-practices-for-the-windows-azure-content-delivery-network.aspx

对于ASP.NET页面，默认行为是将缓存控制设置为私有。在这种情况下， Windows Azure CDN将不会缓存此内容。要覆盖此行为，请使用Response对象更改默认缓存控制设置。

所以到目前为止，我对这个小谜题的结论是你必须密切注意你的缓存控制（由于显而易见的原因，它通常设置为私有）。如果你跳过网络角色方法，TTL默认为72小时，为什么你可能永远不会经历我所经历的;因此它只是开箱即用。

感谢 user728584 让我指向正确的方向。

使用Azure CDN降低性能？

2 个答案: