优化Microsoft Windows Media Services 9series.docx

1、优化Microsoft Windows Media Services 9series本文在技术上提供了对Micorsoft Windows Media Services 9 Series的性能和可量化的概述（包括随windows 2003 server一起发布的WMS的升级版本）。本文表述了WMS性能方面的观点、限制条件和性能监控技术。本文同样展示了一组在可控的试验环境下测试获取得到的一组测试结果和数据。笔者推荐将本文所提供的信息作为一种指南。文中的测试结果是基于特定的硬件配置，它是是对现实世界场景的一种简化。你的流媒体系统的真实能力取决与很多的因素，包括网络拓扑结果，用户使用模式，硬件配置和

2、软件配置。基于本文提供的指南和性能信息，你应该能够来设计，调优和最大化你的服务器能力，从而为你个人目标达到最好的效果。本文包括如下的几个主题： 基本指南：对搭建一个流媒体系统提供基本的指南。 WMS 4.1 VS WMS 9 系列： 比较两个版本的WMS的特点和性能。 瓶颈：为一般的服务器性能问题提供潜在的原因分析和解决方案。 性能评估： 解释WMS 9 在一系列性能和压力测试下如何表现。 高级调优： 提供额外的WMS 9的调优技术。 附录 A-F： 有关于WMS 实验室测试详细的配置和结果。 更多的信息：提供额外资源的信息。基本指南为了保证你的用户能得到最好的体验，参考如下几个基本的指南：

3、限制总的用户数量为你在负载测试中所支持的最大用户数的一半。 确保整体的网络利用率低于最大的网卡容量的50%，或者低于支持普遍比特率的最大吞吐量的50%确保你的服务器有足够可用的内存来支持一个理想的性能水平。无论什么时候尽可能使用专用的流媒体服务器。避免运行额外的高耗CPU的服务，比如IIS或者SQL SERVER。WMS 4.1 VS WMS 9 系列： 比较两个版本的WMS的特点和性能WMS 9系列对比于先前的4.1版本提供了显著的性能提升。下面的列表包括了一些对WMS 9系列的性能增强有贡献特色。 新的对象模型和扩展的插件构架 改进了的I/O和线程模型 通过Fast Streaming技术

4、改进了的用户体验。Fast Streaming技术是由四个组件组成：Fast Start，Fast Cache，Fast Reconnect和Fast Recovery。 更低的磁盘搜索操作，由于获取了更大的数据块。 更多在一个普通场景中同时在线的用户数 内存缓存技术的使用，由于使用了windows server 2003所支持的文件缓存技术。 在UDP传输上更高的包恢复率。 支持Real Time Streaming Portocol（RTSP） 改进了的负载模拟测试工具（Windows Media Load Simulator 9 系列）下面的几个图总结了由WMS4.1到WMS 9的性能提

5、升。第一个图展示了在两个平台上的最大广播用户数的对比。第二个图展示了在两个平台是上的最大点播用户数的对比，点播来源是在一块 RAID 0 SCSI 3 15000 RPM的硬盘。第三个图展示了在两个平台上的最大点播用户数的对比，点播来源是一块单独的SCIS 3 15000 RPM硬盘。Modem/Dial-upDSL/BroadbandIntranet瓶颈当一个进程或者活动的一部分减慢或者阻止了其他部分，从而影响了总体的进展或者性能，这时瓶颈就产生了。在一个WMS系统中常见的瓶颈是CPU，数据源的吞吐量，输出的网络带宽和系统内存。CPU使用率和系统内存瓶颈通常要比数据源吞吐量和网络带宽限制容易

6、识别。最为关键的是你需要识别、移除或者最小化你系统中的所有的瓶颈，从而最大程度上提高WMS的容量和终端用户的用户体验。CPU 计算效率系统管理员倾向于相信这样一种观点：只要CPU使用率没有达到100%，那么他们的系统就是健康的。不幸的是，这种假定并不总是正确的。举例来说，总是有这样一些案例：服务器即使是在CUP使用率非常低的情况下仍然不能接受更多的压力。有几种其他类型的瓶颈并不是由于过高的CPU使用率引起的。这些瓶颈可能会明显的降低终端用户的体验度，而并不需要影响服务器的CPU使用率。通常来说，由于内存换页而引起的系统内存瓶颈可能会导致CUP使用率达到100%。另外一方面，网络带宽和数据源吞吐

7、量则通常不会影响到平均的CPU使用率水平。你可以使用几种不同的程序和工具来监控CUP使用率，包括： WMS在MMC中的插件。在这个插件的detail 面板的Monitor页上提供系统CPU使用率的信息。 Windows任务管理器。 性能监控器：Processor(*)% Processor Time 计数器提供更为详细的CUP使用率信息，比如图表和历史信息。为你的流媒体服务器选择正确的硬件需求，容量和CPU是非常重要的。平均的CPU使用率取决于用户的操作，比如连接到一个流或者流文件，在不同的播放列表之间切换，快进，搜索，或者提交日志。有一个通用的原则，那就是平均的CPU使用率应该不要超过20%

8、，并且并发的用户数应该低于服务器在支持特定的比特率的最大容量的50%。这个指导可能看起来有点保守，但是这是基于一个事实，那就是CPU使用率对于内部服务器操作变化非常大。举例来说：有一台给几千个稳定的用户广播的服务器。依据比特率和服务器，CPU的使用率很容易保持在低于20%的水平。但是如果几百个用户同时试图去连接到服务器或者切换到不同的播放列表，服务器的CUP使用率可能在几秒钟内激增到一个较高的水平。通常来说，对成倍的用户进行流传输要比处理单个用户的请求消耗少的CPU。因此，保持CPU平均负载低于20%必不会对支持最大数量的流媒体用户产生明显的减少。剩下的75%的CPU容量可以用来处理更多高消耗

9、CPU的用户请求，从而减少相应时间和增强用户体验。快进和搜索操作是两种高耗CPU资源的例子，它们能够获得空闲的CPU周期的支持。如果你发现你的服务器的CPU使用率临时达到一个比推荐值高的水平，这时可以避免服务器端实时播放列表的操作。减少Connection rate（per second）limit。减少Fast Start bandwidth per player limit。作为一个基本的永久的原则，考虑升级你的硬件能力来减少平均CPU使用率水平和提供一个高质量的服务给你的用户。处理器数量WMS 9系列很大程度上来依赖于I/O操作。因此，增加处理器的数量并不能有效的增加服务器的处理能力。其

10、他的因素，比如内部总线布局，总线速度，网络接口总线位置，不同处理器之间的中断处理分配和数据源吞吐量容量都对整体的性能有重要的影响。当WMS 服务器使用1Gbps的网卡，测试数据显示双处理器系统能在大多数的情况下提供很好的结果。当服务器使用1Mbps的网卡时，测试显示单处理器服务器能应付大多数情况下的负载。值得推荐的是，你可以使用4个或者以上的处理器的服务器来对无线网络进行流传输或者使用高耗CPU的插件。下面的图显示服务器在使用1/2/4/8个CPU的情况下，对22Kbps和300Kbps的RTSPU进行流传输的时候，服务器所能支持的最大用户数。粗略的说，在处理器数量线性增加的同时，连接的用户数

11、呈几何数增长。这种行为主要是由I/O资源限制引起的。由于I/O的限制，增加的处理器能力并没有完全被利用。对于更多测试中使用的8处理器的服务器信息，请参考附录A（参考硬件编号S3）。 请依据以下指南来达到在处理器能力方面最优的服务器性能： 限制平均的CPU使用率低于或者等于全部处理器能力的25%。 当流传输给成倍用户时，避免运行高耗CPU的操作。 如果你的CPU使用率高于正常的水平，请尽可能多的关闭程序，包括WMS在MMC总的插件。数据源吞吐量WMS 9 系列支持很多种流媒体数据，支持内建和非微软数据源插件。默认安装的WMS包括一组插件，这些插件能够提供对网络内容（从其他WMS或者encoder

12、传输的流媒体文件），HTTP下载和文件数据源（存储在本地或者远程文件系统）。 为了保证一个良好的用户体验，在不考虑数据源的情况下，确保服务器和数据源之间的连接能够维持所需要的数据传输率。数据源可以是简单的存储在本地的流媒体文件。更多复杂的数据源包括从分布式服务器传输的流媒体或者存储在NAS和SAN上的流媒体文件。根据数据源和服务器之间的连接方式（架构，驱动器，等等）的不同，最大的吞吐量和对服务器CPU的利用率变化非常大。对于这些不同的解决方案的特定的性能测试结果和比较并不是本文讨论的范围。请与你的存储方案供应商确认最大可支持的吞吐量和对CPU使用率的影响。发布点类型对于决定你的数据源吞吐量需求

13、是一个关键的因素。广播发布点要比点播发布点更少的数据源消耗。在任何给定的时刻，连接到广播发布点的用户都会收到一份相同数据的拷贝。通常来说，一个广播发布点从数据源接受到一份数据后分割然后分发给所有的用户。相比较，点播发布点则需要为每个用户连接直接进行读数据，从而导致数据源负载的增加。会有一些这样的情况，一些点播用户会经常范围一些非常受欢迎的文件。为了提供这种情况的性能，内建的WMS文件数据源插件会利用Windows server 2003操作系统的文件缓存功能。这样，如果一些点播的用户频繁访问同一个数据源，WMS会从服务器的缓存的获取数据而不是从原始的数据源文件。这样就能明显的帮助减轻数据源吞吐

14、量的需求。默认的情况下，当数据源来自本地NTFS或者FAT文件系统时候，WMS会利用文件缓存功能。文件缓存功能对其他存储系统的文件类型的支持取决于驱动器的实现。请和你的存储解决方案供应商确认是否他们的解决方案支持Windows server 2003的文件缓存技术。下面的图显示了PhysicalDisk（_Total）Disk Read Bytes/sec 和Windows Media ServicesCurrent File Read Rate(Kbps) 两个计数器的对比，分别使用RTSPT协议来传输22Kbps和300Kbps的流媒体。这些图描述了一个理想的场景，那就是所用的用户都从一个

15、单个的内容接受点播流。在这个场景中，WMS从内建的文件数据源读取的总量呈线性增长，而同时从磁盘获取的总量却大概维持稳定和几个较低的水平。你可以观察几个性能指标来诊断不同数据源层次的状态。最主要用来衡量数据源瓶颈的计数器是：Performance MonitorWindows Media ServicesCurrent Late Read Rate。这个计数器，适用于服务器和发布点级别。指示当前那些完成了但是有延迟的读操作的数量。你可以在发布点级别使用这个计数器来判断特定的发表点是不是有读延迟现象。如果这些计数器的值在一段时间内大于0则表示一个或者多个发表点正经历数据源吞吐量的问题。在这种情况下

16、，你可以使用Windows Media ServiceCurrent File Read Rate(Kbps) 和Windows Media ServiceCurrent Incoming Bandwidth（Kbps）计数器来确定进来的数据率。对于服务器的数据源，你可以适用特定的计数器比如：Local File SystemPhysical Disks, Network Data SourceNetwork Interface 和Remote File SystemNTB connections来确定那些网络接口正处在一个什么样的水平。如果你发现数据源使用的一个或者多个接口对系统的瓶颈有责任

17、的话，你可以考虑对它们进行升级，加多更多的资源，或者将负载分布到不同的服务器上去。数据源能够被分割为3组类型：本地缓存（在内存中），远程缓存，和不缓存。本地缓存（在内存中）的情况发生在当大多数的用户都访问一小部分流媒体文件时。增加更多的用户的话通常会导致更多的内存使用和CPU使用率。根据这种使用的数据源，这样的增加并不会导致读延迟。另一方面，服务器CPU使用率达到一个较高的水平，并且Windows Media ServicesCurrent Late Send Rate 计数器增加并超过0。这种结果是典型的由CPU瓶颈所导致的，下面会有一个章节详细讨论这个问题。本地缓存的一个常见的例子就是大多

18、数的用户访问一个存储在本地文件系统的文件。远程缓存或者无缓存的情况发生当多用户访问多文件的时候。在这种情况下，无论文件内容是否被远程缓存或者根本没有被缓存，当服务器和数据源之间的连接达到吞吐量的限制或者数据源的容量已经达到极限，读延迟就发生了。NAS和SAN架构远程缓存很好的例子，这种情况下，最大的吞吐量取决于网络状况或者私有接口的容量。不缓存的例子则是多用户访问存储在本地的多流媒体文件，这种情况下，最大的吞吐量通常取决于磁盘或者磁盘接口的容量。 在很多案例中，流入的数据源连接和流出的流传输共享相同的网卡。我们不推荐这种配置，因为这样会很容易使网卡产生吞吐量瓶颈。 所有在本文中出现的点播的性能

19、测试都是使用的单个存储在本地NTFS文件系统的流媒体。选择这种本地缓存的方式是为了证实WMS所能支持的最大容量，而不受任何数据源硬件的限制影响。在点播并没有缓存的情况下，这时WMS所支持的容量取决于数据源的硬件配置和吞吐量能力。在多播中当客户分发的情况增加时，由于缓存命中率的减少会产生多余的数据源容量。附录B记录了一系列的性能测试结果。使用硬件S1和S2的配置，WMS可以支持22000个以22 Kbps发布的流，而吞吐量大概在470 Mbps。另一个测试结果表明WMS能够支持990个以1 Mbps发布的流，而吞吐量大概在970 Mbps。 下面的指南能帮你减少在数据源上有限制的系统上的瓶颈。

20、避免将流媒体文件存储在操作系统所在的磁盘。 在流媒体所在的磁盘禁止页交换操作。 在任何时候如果可能的话，存储流媒体的本地磁盘或者存储系统支持Windows Server 2003的文件缓存技术。 在多服务器环境里，如果数据的容量和更新频率没有被禁止的话，在所有的服务器之间复制流媒体文件。如果复制数据不是最有效率的话，分割数据并在多服务器上存放和传输。 当远程存储文件时，避免在同一个连接上进行流入和流出的传输，为每个任务使用独立的接口。 不要从HTTP源来重新获取数据。只使用HTTP来进行动态播放列表的处理和获取。高级 FF/RW包含在Windows Media Server 2003 SP1里

21、面的WMS的升级包里面包含高级FF/RW 媒体程序插件，它能够帮助减轻在用户提交快进或者快退请求时所产生的数据源瓶颈。这种插件在高比特率传输的场景的时候非常有效，比如在IPTV系统中进行点播传输。使用这个插件，内容提供方需要将文件在多个FF/RW比率上进行编码。然后这些文件这些文件才能在用户以欺骗模式发送请求的时候被访问。更多的信息，请参阅WMS的帮助文件中理解高级FF/RW一节。 有这样一个案例，一个用户以普通的速度播放60s，然后以5倍的速度快进60s，最后恢复普通速度回放60s。下面的图显示了WMServer.exe 进程的I/O Read Bytes/sec的数据情况。注意到使用高级F

22、F/RW的时候，byte read要明显的低。当很多用户同时使用快进模式的时候，此插件能够很大程度上减少后端数据源的传输。带宽造成带宽瓶颈的两个主要的方面是服务器网卡的总体容量和服务器之间、服务器和用户之间的网络拓扑和容量。本文不讨论第二个方面，因为大部分的变动的原因超出了WMS的控制范围。两种最常见的网卡的传输速度为100Mbps和1Gbps。在硬件的支持下，WMS能够使用网卡95%容量。使用典型的服务器配置，使用一小部分CPU资源WMS就能够达到单个100Mbps网卡的极限。因此，本文重点会放在使用1Gbps的网卡所获得的性能测试结果上，而不会讨论使用一个或者多个100Mbps的网卡的服务

23、器配置。为了使用WMS获得最大的全局吞吐量，我们推荐使用1Gbps的网卡。使用1Gbps的网卡能得到非常好的结果，可以单个服务器的吞吐量水平达到960Mbps。当在硬件S1和S2上使用2个或2个以上的网卡，CPU的使用率便成为了限制因素。尽管如此，在性能测试中，当使用2个1Gbps的网卡的时候，WMS能够达到高于1.3Gbps的吞吐量水平。计算器Windows Media ServicesCurrent Late Send Rate是评估网络瓶颈的相关的性能计数器。每当WMS发送的数据包比预定的发送时间延迟最少1.5s，WMS便报告一次late send。Late read可能由于可用的带宽不

24、能满足所有的用户，也可能处理器时间周期的短缺，也可能是原始的数据源的原因。第二和第三并不与网络瓶颈相关。为了确认网络瓶颈是不是late read产生的原因，需要考虑如下几个因素：持续时间少于5s的late send通常表明服务器临时过载或者不能及时地获取数据源数据。客户端缓存有足够的数据以维持回放直到服务器的流媒体恢复到正常水平。通常导致系统临时过载的原因是有新的客户连接，或者大量同时的客户请求（比如搜索，快进等等）或者是在 广播时服务端播放列表的转换。如果系统过载是由于客户活动，可以考虑减少连接频率限制和保留多余的CPU资源用来处理客户请求。持续超过10s的late send并且伴随较低的C

25、PU使用率和无late read的情况通常表明有对外的网络瓶颈。检查Windows Media ServicesCurrent Player Allocated Bandwidth(Kbps) 和Windows Media ServicesCurrent Player Send Rate(Kbps) 两个性能计数器来确定是否是late send导致的网络瓶颈。分配的带宽和实际用户使用的send rate之间的差异表明客户接受数据的速度不足够快。注意网络瓶颈还可能由本地接口的限制或者发生你的网络之外的其他远程带宽限制所引起。在这种情况下，有可以遵循以下做法：增加你的网络接口和外部网络容量，限制最

26、多的用户数量，或者增加更多的流服务器。如果你不愿意改变服务器配置，那么网络瓶颈则有可能会影响到用户回放的质量。持续超过10s的late send并且伴随较低的CPU使用率和持续的late read的情况通常表明服务器不能足够快地从数据源接受数据。这是典型的数据源瓶颈。只有那些连接到收late read影响的发表点的用户才会出现回放问题。而连接到其他发表点的用户可能能够正常接受数据而不会有回放的问题。 持续的late send 并伴随非常高的CPU使用率，不管有无late read，通常表明服务器上的一种或者多种资源已经耗尽。在这种情况下，很多用户会有回放的问题。这是典型到由于CPU或者内存瓶颈

27、而引发的例子。在这个案例中，你应该减少最大用户数或者增加更多的服务器来均衡负载。下面的指南能帮助你优化服务器性能和减少网络相关的问题： 使用Windows Media Load Simulator 9系列进行性能测试来确定你的服务器的最大容量和建立合理的限制。 限制总体的用户带宽为最大网络带宽的50%或者最传输普通比特率时的总体带宽的50%，或者更低。要获得限制和比特率总体带宽的更多信息请参见限制一节和附录B。 使用1Gbps的网卡来最大化你的服务器容量，多播的情况除外。 使用独立的网卡来传输流入和流出的数据，如果内容是远程存储的话。 确保网卡和网络构架支持全双工传输。 如果你的网络架构运行，

28、在广播点启用多播流传输。系统内存有几种工具可以用来跟踪系统内存，包括Windows任务管理器和性能监控的Process(WMServer)Private Byte 计数器。作为一个通用原则，系统内存应该总是要比WMS的进程（WMServer.exe）使用的内存要多。理想的情况是，对于多播的情况，WMS服务器应该具备比达到目标播放效果至少多30%的内存。而对于点播的情况，我们推荐至少要多出50%，因为操作系统需要使用更多的内存来进行文件缓存操作。每个用户的平均内存取决于发布点的类型和内容的编码设置，比如比特率，包大小和音频、视频流的数量。请参看附录B以获取更多有关每个用户平均内存需求的信息。根据

29、使用模式，目标用户数，客户在不同发布流中的分布和不同的发表点类型，你要能够估算出你的流媒体系统需要多少内存。如果你的服务器有足够多的物理内存，多余的内存能减少由于内存换页导致的延迟从而增加服务器整体的性能。作为流媒体的特性，WMS使用一个小的时间窗口来发送数据到所连接的用户。一个内存紧张的系统里面，当服务器处理，发送或者从数据源读取数据的时候，内存换页操作可能引起不可预料的延迟。Late send的结果通常会影响到整体的客户体验度。如果服务器有足够多的可用内存，操作系统能最大程度的利用文件缓存从而减少数据源吞吐量瓶颈造成的影响。有几个决定系统内存需求的因素。举例来说，广播发布的流通常需要比点播

30、发布的流较少的内存。连接协议同样也对整体占用的内存有影响。通常来说，基于TCP的协议需要的系统内存少于基于UDP的协议，因为WMS需要为UDP连接存储额外的信息。依据不同的比特率，WMS需要在服务器内存中存储最多10s的发送数据用来满足包的重新发送请求（当UDP包在传输过程中丢失）。需要了解更多WMS支持的协议和之间的性能区别，参见本文协议一节。依据不同的比特率，点播用户连接需要3-10倍于广播连接的内存。另外，使用UPD协议的点播连接通常需要2-3倍使用TCP协议的连接。在实践中，一台4G内存的服务器最多支持22800个22Kbps的广播音频流和最多22000个22Kbps的点播音频流。和其他的32位应用程序一样，WMS有一个内存的极限，这个极限限制了服务器最大的容量。如果WMS进程内存使用达到2G，参看本文服务器命名空间设置一节来获知如何减少每个用户的平均内存使用。下面的指南能抱着你优化服务器性能： 根据目标性能水平和客户分布模式来计算所需的最优化的内存容量。 提供高于WMS进行广播而需的内存容量30%的系统容量。 提供高于WMS进行点播而需内存容量的50%的系统容量，从而最大化文件缓存容量和较少内存换页操作。