我已经负责为streamvideo设置CDN帐户，但实际上并没有运行将托pipe内容的网站。 我如何testing已发布的RTMPurl是否正常工作？ 我是否需要使用Flashvideo播放器创buildtesting页，或者是否有一个简单的工具可以使用可用于testing的RTMPstream？ 该URL格式如下： rtmp://example.fcod.llnwd.net/a1111/e11/test/example/file.flv
我为一家财富500强公司工作，该公司正在努力准确衡量高可用性应用程序的性能和可用性（例如，5秒页面到页面导航的应用程序可达99.5％）。 我们考虑计划和计划外宕机时间来确定这个可用性数字。 不过，我们最近又join了CDN，这使我们的指标变得复杂一些。 CDN现在可以处理大约75％的stream量，同时将余下的数据发送到我们自己的服务器。 我们试图测量我们所说的“真正的用户体验”（即，我们的testing脚本模拟一个典型的用户点击应用程序）。这些监控脚本位于我们的networking之外，这意味着我们正在使用CDN的约75％时间。 pipe理层决定，我们采取最坏的情况来衡量可用性。 所以，如果我们的原始服务器有问题，但是CDN服务内容还不错，我们仍然会受到影响。 反过来也是如此。 我的想法是，只要“用户体验”成功，我们就不应该不必要地惩罚自己。 毕竟，CDN有提高性能和可用性！ 我只是想知道，如果有人知道其他财富500强公司如何计算他们的可用性数字？ 例如，我看着一个使用CDN的店面（apple.com），这个店面使用的CDN似乎从来没有出现过（除非将要成为一个重要的产品宣告）。拥有一些硬性的，事实的数据是件好事，因为我不喜欢我们不相信我们需要在这些指标上不必要地伤害自己。 我们正在根据这些数字做出商业决定。 但是，我可以说，鉴于pipe理层可以看到这些指标，问题得到解决和快速解决（阅读：我们快速地浏览了繁文</s>节）。不幸的是，作为开发人员，我不希望pipe理层思考由于某些外部因素（即CDN）正在影响这些数字，所以应用程序已经启动或closures。 思考？ （我错误地在StackOverflow上发布了这个问题，对于交叉post提前抱歉）
我正在计划将我的静态文件移动到Google的App Engine。 我想知道这是不是一个好主意。 我已经读过，Google可能会将您的文件caching在多个位置，这在我看来是一件好事。 GAE插件在eclipse中的设置也应该很容易。 但是我仍然对这个performance有怀疑。 App Engine的设置是否针对静态内容进行了优化。 现在我的Nginx服务器是我的静态内容，App Engine的执行方式是一样的。 有没有其他的起伏使用这种方法？
在什么时候将CDN（内容交付networking）添加到您的网站是值得的？ 将它用于Web应用程序的相对较低stream量的网站是否有意义？ 客户遍布美国。 CDN甚至会为我的场景提供一个明显的差异，或者只有在真正达到可扩展性级别时才显示效果？ 编辑：有关服务器设置的信息，目前它是共享主机环境上的单个ASP.NET实例。 什么会进入CDN将是一些图像文件，jQuery相关的文件（我知道谷歌提供了一个核心的CDN），CSS文件，可能是一些中等大小的PDF文件。
指向同一个域的多个Alogging似乎几乎专门用于实现DNS Round Robin作为一种便宜的负载平衡技术。 针对DNS RR的通常警告是对高可用性不利。 当一个IPclosures时，客户端将继续使用它几分钟。 负载平衡器通常被认为是更好的select。 这两个要求并不完全正确： 当stream量是HTTP时，大多数HTML浏览器能够自动尝试下一个Alogging（如果前一个logging已closures），而不需要新的DNS查询。 在这里阅读第3.1章 。 当涉及多个数据中心时，DNS RR是通过它们分配stream量的唯一select。 那么，在多个数据中心和HTTPstream量的情况下，使用DNS RR是确保在一个数据中心发生故障时立即进行故障切换的唯一方法吗？ 谢谢， 华伦天奴 编辑： 当然，每个数据中心都有一个带有热备份的本地负载均衡器。 牺牲即时故障切换的会话亲和力是可以的。 AFAIK DNSbuild议一个数据中心而不是另一个数据中心的唯一方法是只回复与该数据中心相关的IP（或IP）。 如果数据中心变得无法访问，那么所有这些IP也是不可访问的。 这意味着，即使智能HTML浏览器能够立即尝试另一个Alogging，所有的尝试都将失败，直到本地caching条目到期，并完成新的DNS查找，获取新的工作IP（我假设DNS自动build议新的数据中心，当一个失败）。 所以，“聪明的DNS”不能保证即时的故障切换。 相反，DNS轮询允许它。 当一个数据中心出现故障时，智能HTML浏览器（大多数）会立即尝试其他caching的Alogging跳到另一个（工作）的数据中心。 所以，DNS循环不保证会话亲和性或最低的RTT，但似乎是当客户端是“智能”HTML浏览器时确保即时故障转移的唯一方法。 编辑2： 有人build议将TCP Anycast作为一个明确的解决scheme。 在本文中（第6章）解释了Anycast故障切换与BGP收敛有关。 为此，Anycast可以使用15分钟到20秒来完成。 在拓扑结构为此优化的networking上可能需要20秒。 可能只有CDN运营商可以授予这种快速失败。 编辑3：* 我做了一些DNS查找和traceroute（也许一些专家可以仔细检查）和： 使用TCP Anycast的唯一CDN似乎是CacheFly，CDNnetworking和BitGravity等其他运营商使用CacheFly。 似乎他们的边缘不能用作反向代理。 因此，它们不能用于授予即时故障转移。 Akamai和LimeLight似乎使用地理感知DNS。 但！ 他们返回多个Alogging。 从traceroute看来，返回的IP在同一个数据中心上。 所以，我对当一个数据中心崩溃时如何提供100％的SLA感到困惑。