优化Microsoft Windows Media Services 9series

本文在技术上提供了对MicorsoftWindowsMediaServices9Series的性能和可量化的概述（包括随windows2003server一起发布的WMS的升级版本）。本文表述了WMS性能方面的观点、限制条件和性能监控技术。本文同样展示了一组在可控的试验环境下测试获取得到的一组测试结果和数据。笔者推荐将本文所提供的信息作为一种指南。文中的测试结果是基于特定的硬件配置，它是是对现实世界场景的一种简化。你的流媒体系统的真实能力取决与很多的因素，包括网络拓扑结果，用户使用模式，硬件配置和软件配置。基于本文提供的指南和性能信息，你应该能够来设计，调优和最大化你的服务器能力，从而为你个人目标达到最好的效果。本文包括如下的几个主题：基本指南：对搭建一个流媒体系统提供基本的指南。WMS4.1VSWMS9系列：比较两个版本的WMS的特点和性能。瓶颈：为一般的服务器性能问题提供潜在的原因分析和解决方案。性能评估：解释WMS9在一系列性能和压力测试下如何表现。高级调优：提供额外的WMS9的调优技术。附录A-F：有关于WMS实验室测试详细的配置和结果。更多的信息：提供额外资源的信息。基本指南为了保证你的用户能得到最好的体验，参考如下几个基本的指南：限制总的用户数量为你在负载测试中所支持的最大用户数的一半。确保整体的网络利用率低于最大的网卡容量的50%，或者低于支持普遍比特率的最大吞吐量的50%确保你的服务器有足够可用的内存来支持一个理想的性能水平。无论什么时候尽可能使用专用的流媒体服务器。避免运行额外的高耗CPU的服务，比如IIS或者SQLSERVER。WMS4.1VSWMS9系列：比较两个版本的WMS的特点和性能WMS9系列对比于先前的4.1版本提供了显著的性能提升。下面的列表包括了一些对WMS9系列的性能增强有贡献特色。新的对象模型和扩展的插件构架改进了的I/O和线程模型通过FastStreaming技术改进了的用户体验。FastStreaming技术是由四个组件组成：FastStart，FastCache，FastReconnect和FastRecovery。更低的磁盘搜索操作，由于获取了更大的数据块。更多在一个普通场景中同时在线的用户数内存缓存技术的使用，由于使用了windowsserver2003所支持的文件缓存技术。在UDP传输上更高的包恢复率。支持RealTimeStreamingPortocol（RTSP）改进了的负载模拟测试工具（WindowsMediaLoadSimulator9系列）下面的几个图总结了由WMS4.1到WMS9的性能提升。第一个图展示了在两个平台上的最大广播用户数的对比。第二个图展示了在两个平台是上的最大点播用户数的对比，点播来源是在一块RAID0SCSI315000RPM的硬盘。第三个图展示了在两个平台上的最大点播用户数的对比，点播来源是一块单独的SCIS315000RPM硬盘。Modem/Dial-upDSL/BroadbandIntranet瓶颈当一个进程或者活动的一部分减慢或者阻止了其他部分，从而影响了总体的进展或者性能，这时瓶颈就产生了。在一个WMS系统中常见的瓶颈是CPU，数据源的吞吐量，输出的网络带宽和系统内存。CPU使用率和系统内存瓶颈通常要比数据源吞吐量和网络带宽限制容易识别。最为关键的是你需要识别、移除或者最小化你系统中的所有的瓶颈，从而最大程度上提高WMS的容量和终端用户的用户体验。CPU计算效率系统管理员倾向于相信这样一种观点：只要CPU使用率没有达到100%，那么他们的系统就是健康的。不幸的是，这种假定并不总是正确的。举例来说，总是有这样一些案例：服务器即使是在CUP使用率非常低的情况下仍然不能接受更多的压力。有几种其他类型的瓶颈并不是由于过高的CPU使用率引起的。这些瓶颈可能会明显的降低终端用户的体验度，而并不需要影响服务器的CPU使用率。通常来说，由于内存换页而引起的系统内存瓶颈可能会导致CUP使用率达到100%。另外一方面，网络带宽和数据源吞吐量则通常不会影响到平均的CPU使用率水平。你可以使用几种不同的程序和工具来监控CUP使用率，包括：WMS在MMC中的插件。在这个插件的detail面板的Monitor页上提供系统CPU使用率的信息。Windows任务管理器。性能监控器：Processor(*)%ProcessorTime计数器提供更为详细的CUP使用率信息，比如图表和历史信息。为你的流媒体服务器选择正确的硬件需求，容量和CPU是非常重要的。平均的CPU使用率取决于用户的操作，比如连接到一个流或者流文件，在不同的播放列表之间切换，快进，搜索，或者提交日志。有一个通用的原则，那就是平均的CPU使用率应该不要超过20%，并且并发的用户数应该低于服务器在支持特定的比特率的最大容量的50%。这个指导可能看起来有点保守，但是这是基于一个事实，那就是CPU使用率对于内部服务器操作变化非常大。举例来说：有一台给几千个稳定的用户广播的服务器。依据比特率和服务器，CPU的使用率很容易保持在低于20%的水平。但是如果几百个用户同时试图去连接到服务器或者切换到不同的播放列表，服务器的CUP使用率可能在几秒钟内激增到一个较高的水平。通常来说，对成倍的用户进行流传输要比处理单个用户的请求消耗少的CPU。因此，保持CPU平均负载低于20%必不会对支持最大数量的流媒体用户产生明显的减少。剩下的75%的CPU容量可以用来处理更多高消耗CPU的用户请求，从而减少相应时间和增强用户体验。快进和搜索操作是两种高耗CPU资源的例子，它们能够获得空闲的CPU周期的支持。如果你发现你的服务器的CPU使用率临时达到一个比推荐值高的水平，这时可以避免服务器端实时播放列表的操作。减少Connectionrate（persecond）limit。减少FastStartbandwidthperplayerlimit。作为一个基本的永久的原则，考虑升级你的硬件能力来减少平均CPU使用率水平和提供一个高质量的服务给你的用户。处理器数量WMS9系列很大程度上来依赖于I/O操作。因此，增加处理器的数量并不能有效的增加服务器的处理能力。其他的因素，比如内部总线布局，总线速度，网络接口总线位置，不同处理器之间的中断处理分配和数据源吞吐量容量都对整体的性能有重要的影响。当WMS服务器使用1Gbps的网卡，测试数据显示双处理器系统能在大多数的情况下提供很好的结果。当服务器使用1Mbps的网卡时，测试显示单处理器服务器能应付大多数情况下的负载。值得推荐的是，你可以使用4个或者以上的处理器的服务器来对无线网络进行流传输或者使用高耗CPU的插件。下面的图显示服务器在使用1/2/4/8个CPU的情况下，对22Kbps和300Kbps的RTSPU进行流传输的时候，服务器所能支持的最大用户数。粗略的说，在处理器数量线性增加的同时，连接的用户数呈几何数增长。这种行为主要是由I/O资源限制引起的。由于I/O的限制，增加的处理器能力并没有完全被利用。对于更多测试中使用的8处理器的服务器信息，请参考附录A（参考硬件编号S3）。请依据以下指南来达到在处理器能力方面最优的服务器性能：限制平均的CPU使用率低于或者等于全部处理器能力的25%。当流传输给成倍用户时，避免运行高耗CPU的操作。如果你的CPU使用率高于正常的水平，请尽可能多的关闭程序，包括WMS在MMC总的插件。数据源吞吐量WMS9系列支持很多种流媒体数据，支持内建和非微软数据源插件。默认安装的WMS包括一组插件，这些插件能够提供对网络内容（从其他WMS或者encoder传输的流媒体文件），HTTP下载和文件数据源（存储在本地或者远程文件系统）。为了保证一个良好的用户体验，在不考虑数据源的情况下，确保服务器和数据源之间的连接能够维持所需要的数据传输率。数据源可以是简单的存储在本地的流媒体文件。更多复杂的数据源包括从分布式服务器传输的流媒体或者存储在NAS和SAN上的流媒体文件。根据数据源和服务器之间的连接方式（架构，驱动器，等等）的不同，最大的吞吐量和对服务器CPU的利用率变化非常大。对于这些不同的解决方案的特定的性能测试结果和比较并不是本文讨论的范围。请与你的存储方案供应商确认最大可支持的吞吐量和对CPU使用率的影响。发布点类型对于决定你的数据源吞吐量需求是一个关键的因素。广播发布点要比点播发布点更少的数据源消耗。在任何给定的时刻，连接到广播发布点的用户都会收到一份相同数据的拷贝。通常来说，一个广播发布点从数据源接受到一份数据后分割然后分发给所有的用户。相比较，点播发布点则需要为每个用户连接直接进行读数据，从而导致数据源负载的增加。会有一些这样的情况，一些点播用户会经常范围一些非常受欢迎的文件。为了提供这种情况的性能，内建的WMS文件数据源插件会利用Windowsserver2003操作系统的文件缓存功能。这样，如果一些点播的用户频繁访问同一个数据源，WMS会从服务器的缓存的获取数据而不是从原始的数据源文件。这样就能明显的帮助减轻数据源吞吐量的需求。默认的情况下，当数据源来自本地NTFS或者FAT文件系统时候，WMS会利用文件缓存功能。文件缓存功能对其他存储系统的文件类型的支持取决于驱动器的实现。请和你的存储解决方案供应商确认是否他们的解决方案支持Windowsserver2003的文件缓存技术。下面的图显示了PhysicalDisk（_Total）DiskReadBytes/sec和WindowsMediaServicesCurrentFileReadRate(Kbps)两个计数器的对比，分别使用RTSPT协议来传输22Kbps和300Kbps的流媒体。这些图描述了一个理想的场景，那就是所用的用户都从一个单个的内容接受点播流。在这个场景中，WMS从内建的文件数据源读取的总量呈线性增长，而同时从磁盘获取的总量却大概维持稳定和几个较低的水平。你可以观察几个性能指标来诊断不同数据源层次的状态。最主要用来衡量数据源瓶颈的计数器是：PerformanceMonitorWindowsMediaServicesCurrentLateReadRate。这个计数器，适用于服务器和发布点级别。指示当前那些完成了但是有延迟的读操作的数量。你可以在发布点级别使用这个计数器来判断特定的发表点是不是有读延迟现象。如果这些计数器的值在一段时间内大于0则表示一个或者多个发表点正经历数据源吞吐量的问题。在这种情况下，你可以使用WindowsMediaServiceCurrentFileReadRate(Kbps)和WindowsMediaServiceCurrentIncomingBandwidth（Kbps）计数器来确定进来的数据率。对于服务器的数据源，你可以适用特定的计数器比如：LocalFileSystemPhysicalDisks,NetworkDataSourceNetworkInterface和RemoteFileSystemNTBconnections来确定那些网络接口正处在一个什么样的水平。如果你发现数据源使用的一个或者多个接口对系统的瓶颈有责任的话，你可以考虑对它们进行升级，加多更多的资源，或者将负载分布到不同的服务器上去。数据源能够被分割为3组类型：本地缓存（在内存中），远程缓存，和不缓存。本地缓存（在内存中）的情况发生在当大多数的用户都访问一小部分流媒体文件时。增加更多的用户的话通常会导致更多的内存使用和CPU使用率。根据这种使用的数据源，这样的增加并不会导致读延迟。另一方面，服务器CPU使用率达到一个较高的水平，并且WindowsMediaServicesCurrentLateSendRate计数器增加并超过0。这种结果是典型的由CPU瓶颈所导致的，下面会有一个章节详细讨论这个问题。本地缓存的一个常见的例子就是大多数的用户访问一个存储在本地文件系统的文件。远程缓存或者无缓存的情况发生当多用户访问多文件的时候。在这种情况下，无论文件内容