Performance 使用Azure CDN会降低性能？
我在Azure上做了很多CDN的实验，我认为在使用web角色成功安装之后，我是安全的 为什么选择网络角色？ 好吧，我想要压缩和缓存头的好处，但我用普通的blob方式无法获得。作为额外的奖励；还消除了区分大小写的约束 选择CDN服务就足够了；以前的所有内容都是从同一个域提供的，现在我或多或少地从cdn.cuemon.net提供所有“静态”内容。从理论上讲，这应该会提高性能，因为与仅一个域相比，并行浏览器可以将内容收集分散到“多个”域 不幸的是，这导致性能下降，我认为这与内容提供之前的HOB数量有关（使用tracert命令）： 从上面的跟踪路径可以看出，所有外部内容都会延迟一段时间。 值得注意的是，Azure服务设置在北欧，我定居在丹麦，为什么这条跟踪路线有点。。隐马尔可夫模型。。过了头 另一个问题可能是web角色是两个额外的小实例；我还没有时间尝试使用两个小实例，但我知道Microsoft将额外的小实例限制在5Mb/s的WAN上，而small及以上的WAN具有100Mb/s 我只是不确定这是否也适用于CDN 无论如何-非常感谢任何帮助和/或解释 让我声明，我对Azure平台非常满意——我只是对上述问题感到好奇 更新 不带-d选项的新tracert 受user728584的启发，我研究并发现了这篇文章，我将进一步研究公共缓存控制和CDN 这并不能解释跳数过多的现象，但我希望一位技术娴熟的网络专业人士能够帮助解决这一问题Performance 使用Azure CDN会降低性能？,performance,azure,routing,cdn,trace,Performance,Azure,Routing,Cdn,Trace,我在Azure上做了很多CDN的实验，我认为在使用web角色成功安装之后，我是安全的 为什么选择网络角色？ 好吧，我想要压缩和缓存头的好处，但我用普通的blob方式无法获得。作为额外的奖励；还消除了区分大小写的约束 选择CDN服务就足够了；以前的所有内容都是从同一个域提供的，现在我或多或少地从cdn.cuemon.net提供所有“静态”内容。从理论上讲，这应该会提高性能，因为与仅一个域相比，并行浏览器可以将内容收集分散到“多个”域 不幸的是，这导致性能下降，我认为这与内容提供之前的HOB数量有关
请放心，我将根据我的调查结果向您发布消息。不说明显的问题，但我假设您已将缓存控制HTTP头设置为一个很大的数字，以便在您进行跟踪测试时，您的内容不会从CDN缓存中删除，也不会从Blob存储中提供服务 您附近有很多边缘服务器，因此我希望它的性能会更好：“Windows Azure CDN节点位置” Maarten Balliauw有一篇关于CDN的用法和用例的优秀文章（这可能有帮助吗？）
不确定这是否有帮助，有趣的…好的，在我实现了公共缓存控制头之后，CDN似乎做了预期的事情；从CDN群集中x个节点交付内容 上述限制条件是它是有经验的——它不是为具体验证而测量的 然而，这一联系支持了我的理论： blob的生存时间（TTL）设置控制CDN边缘服务器在从blob存储中的源请求新副本之前返回缓存资源副本的时间。一旦该期限到期，一个新请求将强制CDN服务器再次从原始blob中检索资源，此时它将再次缓存该资源 这是我假定的挑战；CDN引用的资源一直在共享原始blob 此外，还必须为该链接提供积分（由用户728584提供） 现在的最后一个环节是： 对于ASP.NET页面，默认行为是将缓存控制设置为私有。在这种情况下，Windows Azure CDN将不会缓存此内容。若要覆盖此行为，请使用响应对象更改默认缓存控制设置 因此，到目前为止，我对这个小谜题的结论是，您必须密切关注您的缓存控制（由于明显的原因，通常设置为private）。如果您跳过web角色方法，TTL默认为72小时，为什么您可能从未体验过我的体验；因此，它只是开箱即用
感谢user728584为我指明了正确的方向。那么，您的web角色是从CDN中提取数据并将其传递给用户，还是您的web角色只是传递HTTP页面，而用户的浏览器是从CDN请求静态内容？我在web角色中所做的唯一事情就是在NET生命周期；这将添加适当的缓存头和压缩，所有内容都是从/cdn文件夹“提供”的！当然，我需要检查我的缓存控制头，因为我相信我不接受代理缓存（doooh！）。尽管如此；跃点计数仍然令人不安，响应时间pr.hop。我会查看你的文章-谢谢分享，伙计。好了，我现在已经更新了我的CDN，缓存控制设置为public。您可以在这里看到我的标题：
HTTP/1.1 200确定缓存控制：公共，必须重新验证，无转换，最大年龄=604800内容类型：应用程序/x-javascript接受范围：字节ETag:“2036992d85fc262d9ae5dbdfd7a1eb4a”服务器：Microsoft IIS/7.0 x-Powered-By:ASP.NET内容长度：1376年龄：371日期：Thu，2012年4月26日22:15:44 GMT上次修改时间：2012年4月3日星期二00:09:19 GMT到期时间：2012年5月3日星期四22:09:34 GMT连接：保持活动状态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]