优化Microsoft Windows Media Services 9 Series

  优化Microsoft Windows Media Services 9 Series

本文在技术上提供了对Micorsoft Windows Media Services 9 Series的性能和可量化的概述（包括随windows 2003 server一起发布的WMS的升级版本）。本文表述了WMS性能方面的观点、限制条件和性能监控技术。本文同样展示了一组在可控的试验环境下测试获取得到的一组测试结果和数据。

笔者推荐将本文所提供的信息作为一种指南。文中的测试结果是基于特定的硬件配置，它是是对现实世界场景的一种简化。你的流媒体系统的真实能力取决与很多的因素，包括网络拓扑结果，用户使用模式，硬件配置和软件配置。基于本文提供的指南和性能信息，你应该能够来设计，调优和最大化你的服务器能力，从而为你个人目标达到最好的效果。

本文包括如下的几个主题：

l         基本指南：对搭建一个流媒体系统提供基本的指南。

l         WMS 4.1 VS WMS 9 系列： 比较两个版本的WMS的特点和性能。

l         瓶颈：为一般的服务器性能问题提供潜在的原因分析和解决方案。

l         性能评估： 解释WMS 9 在一系列性能和压力测试下如何表现。

l         高级调优： 提供额外的WMS 9的调优技术。

l         附录 A-F： 有关于WMS 实验室测试详细的配置和结果。

l         更多的信息：提供额外资源的信息。

 

 

基本指南

为了保证你的用户能得到最好的体验，参考如下几个基本的指南：

l         限制总的用户数量为你在负载测试中所支持的最大用户数的一半。

l         确保整体的网络利用率低于最大的网卡容量的50%，或者低于支持普遍比特率的最大吞吐量的50%

确保你的服务器有足够可用的内存来支持一个理想的性能水平。

无论什么时候尽可能使用专用的流媒体服务器。避免运行额外的高耗CPU的服务，比如IIS或者SQL SERVER。

WMS 4.1 VS WMS 9 系列： 比较两个版本的WMS的特点和性能

WMS 9系列对比于先前的4.1版本提供了显著的性能提升。下面的列表包括了一些对WMS 9系列的性能增强有贡献特色。

l         新的对象模型和扩展的插件构架

l         改进了的I/O和线程模型

l         通过Fast Streaming技术改进了的用户体验。Fast Streaming技术是由四个组件组成：Fast Start，Fast Cache，Fast Reconnect和Fast Recovery。

l         更低的磁盘搜索操作，由于获取了更大的数据块。

l         更多在一个普通场景中同时在线的用户数

l         内存缓存技术的使用，由于使用了windows server 2003所支持的文件缓存技术。

l         在UDP传输上更高的包恢复率。

l         支持Real Time Streaming Portocol（RTSP）

l         改进了的负载模拟测试工具（Windows Media Load Simulator 9 系列）

 

下面的几个图总结了由WMS4.1到WMS 9的性能提升。第一个图展示了在两个平台上的最大广播用户数的对比。第二个图展示了在两个平台是上的最大点播用户数的对比，点播来源是在一块 RAID 0 SCSI 3 15000 RPM的硬盘。第三个图展示了在两个平台上的最大点播用户数的对比，点播来源是一块单独的SCIS 3 15000 RPM硬盘。

 

 

Modem/Dial-up

 

DSL/Broadband

 

Intranet

 

 

瓶颈

当一个进程或者活动的一部分减慢或者阻止了其他部分，从而影响了总体的进展或者性能，这时瓶颈就产生了。在一个WMS系统中常见的瓶颈是CPU，数据源的吞吐量，输出的网络带宽和系统内存。CPU使用率和系统内存瓶颈通常要比数据源吞吐量和网络带宽限制容易识别。

最为关键的是你需要识别、移除或者最小化你系统中的所有的瓶颈，从而最大程度上提高WMS的容量和终端用户的用户体验。

 

CPU 计算效率

系统管理员倾向于相信这样一种观点：只要CPU使用率没有达到100%，那么他们的系统就是健康的。不幸的是，这种假定并不总是正确的。举例来说，总是有这样一些案例：服务器即使是在CUP使用率非常低的情况下仍然不能接受更多的压力。

有几种其他类型的瓶颈并不是由于过高的CPU使用率引起的。这些瓶颈可能会明显的降低终端用户的体验度，而并不需要影响服务器的CPU使用率。通常来说，由于内存换页而引起的系统内存瓶颈可能会导致CUP使用率达到100%。另外一方面，网络带宽和数据源吞吐量则通常不会影响到平均的CPU使用率水平。

你可以使用几种不同的程序和工具来监控CUP使用率，包括：

l         WMS在MMC中的插件。在这个插件的detail 面板的Monitor页上提供系统CPU使用率的信息。

l         Windows任务管理器。

l         性能监控器："Processor(*)"% Processor Time 计数器提供更为详细的CUP使用率信息，比如图表和历史信息。

 

为你的流媒体服务器选择正确的硬件需求，容量和CPU是非常重要的。平均的CPU使用率取决于用户的操作，比如连接到一个流或者流文件，在不同的播放列表之间切换，快进，搜索，或者提交日志。

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

如果你发现你的服务器的CPU使用率临时达到一个比推荐值高的水平，这时可以

避免服务器端实时播放列表的操作。

减少Connection rate（per second）limit。

减少Fast Start bandwidth per player limit。

作为一个基本的永久的原则，考虑升级你的硬件能力来减少平均CPU使用率水平和提供一个高质量的服务给你的用户。

 

处理器数量

WMS 9系列很大程度上来依赖于I/O操作。因此，增加处理器的数量并不能有效的增加服务器的处理能力。其他的因素，比如内部总线布局，总线速度，网络接口总线位置，不同处理器之间的中断处理分配和数据源吞吐量容量都对整体的性能有重要的影响。

当WMS 服务器使用1Gbps的网卡，测试数据显示双处理器系统能在大多数的情况下提供很好的结果。当服务器使用1Mbps的网卡时，测试显示单处理器服务器能应付大多数情况下的负载。值得推荐的是，你可以使用4个或者以上的处理器的服务器来对无线网络进行流传输或者使用高耗CPU的插件。

下面的图显示服务器在使用1/2/4/8个CPU的情况下，对22Kbps和300Kbps的RTSPU进行流传输的时候，服务器所能支持的最大用户数。粗略的说，在处理器数量线性增加的同时，连接的用户数呈几何数增长。这种行为主要是由I/O资源限制引起的。由于I/O的限制，增加的处理器能力并没有完全被利用。对于更多测试中使用的8处理器的服务器信息，请参考附录A（参考硬件编号S3）。

 

 

 

 

 

l         请依据以下指南来达到在处理器能力方面最优的服务器性能：

l         限制平均的CPU使用率低于或者等于全部处理器能力的25%。

l         当流传输给成倍用户时，避免运行高耗CPU的操作。

l         如果你的CPU使用率高于正常的水平，请尽可能多的关闭程序，包括WMS在MMC总的插件。

 

数据源吞吐量

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

发布点类型对于决定你的数据源吞吐量需求是一个关键的因素。广播发布点要比点播发布点更少的数据源消耗。在任何给定的时刻，连接到广播发布点的用户都会收到一份相同数据的拷贝。通常来说，一个广播发布点从数据源接受到一份数据后分割然后分发给所有的用户。相比较，点播发布点则需要为每个用户连接直接进行读数据，从而导致数据源负载的增加。

会有一些这样的情况，一些点播用户会经常范围一些非常受欢迎的文件。为了提供这种情况的性能，内建的WMS文件数据源插件会利用Windows server 2003操作系统的文件缓存功能。这样，如果一些点播的用户频繁访问同一个数据源，WMS会从服务器的缓存的获取数据而不是从原始的数据源文件。这样就能明显的帮助减轻数据源吞吐量的需求。默认的情况下，当数据源来自本地NTFS或者FAT文件系统时候，WMS会利用文件缓存功能。文件缓存功能对其他存储系统的文件类型的支持取决于驱动器的实现。请和你的存储解决方案供应商确认是否他们的解决方案支持Windows server 2003的文件缓存技术。

 

下面的图显示了PhysicalDisk（_Total）"Disk Read Bytes/sec 和Windows Media Services"Current File Read Rate(Kbps) 两个计数器的对比，分别使用RTSPT协议来传输22Kbps和300Kbps的流媒体。这些图描述了一个理想的场景，那就是所用的用户都从一个单个的内容接受点播流。在这个场景中，WMS从内建的文件数据源读取的总量呈线性增长，而同时从磁盘获取的总量却大概维持稳定和几个较低的水平。

 

 

 

你可以观察几个性能指标来诊断不同数据源层次的状态。最主要用来衡量数据源瓶颈的计数器是：Performance Monitor"Windows Media Services"Current Late Read Rate。这个计数器，适用于服务器和发布点级别。指示当前那些完成了但是有延迟的读操作的数量。你可以在发布点级别使用这个计数器来判断特定的发表点是不是有读延迟现象。

 

如果这些计数器的值在一段时间内大于0则表示一个或者多个发表点正经历数据源吞吐量的问题。在这种情况下，你可以使用"Windows Media Service"Current File Read Rate(Kbps) 和"Windows Media Service"Current Incoming Bandwidth（Kbps）计数器来确定进来的数据率。对于服务器的数据源，你可以适用特定的计数器比如：Local File System"Physical Disks, Network Data Source"Network Interface 和Remote File System"NTB connections来确定那些网络接口正处在一个什么样的水平。如果你发现数据源使用的一个或者多个接口对系统的瓶颈有责任的话，你可以考虑对它们进行升级，加多更多的资源，或者将负载分布到不同的服务器上去。

 

数据源能够被分割为3组类型：本地缓存（在内存中），远程缓存，和不缓存。

 

本地缓存（在内存中）的情况发生在当大多数的用户都访问一小部分流媒体文件时。增加更多的用户的话通常会导致更多的内存使用和CPU使用率。根据这种使用的数据源，这样的增加并不会导致读延迟。另一方面，服务器CPU使用率达到一个较高的水平，并且"Windows Media Services"Current Late Send Rate 计数器增加并超过0。这种结果是典型的由CPU瓶颈所导致的，下面会有一个章节详细讨论这个问题。本地缓存的一个常见的例子就是大多数的用户访问一个存储在本地文件系统的文件。

 

远程缓存或者无缓存的情况发生当多用户访问多文件的时候。在这种情况下，无论文件内容是否被远程缓存或者根本没有被缓存，当服务器和数据源之间的连接达到吞吐量的限制或者数据源的容量已经达到极限，读延迟就发生了。NAS和SAN架构远程缓存很好的例子，这种情况下，最大的吞吐量取决于网络状况或者私有接口的容量。不缓存的例子则是多用户访问存储在本地的多流媒体文件，这种情况下，最大的吞吐量通常取决于磁盘或者磁盘接口的容量。

 

     在很多案例中，流入的数据源连接和流出的流传输共享相同的网卡。我们不推荐这种配置，因为这样会很容易使网卡产生吞吐量瓶颈。

 

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

    

     下面的指南能帮你减少在数据源上有限制的系统上的瓶颈。

l         避免将流媒体文件存储在操作系统所在的磁盘。

l         在流媒体所在的磁盘禁止页交换操作。

l         在任何时候如果可能的话，存储流媒体的本地磁盘或者存储系统支持Windows Server 2003的文件缓存技术。

l         在多服务器环境里，如果数据的容量和更新频率没有被禁止的话，在所有的服务器之间复制流媒体文件。如果复制数据不是最有效率的话，分割数据并在多服务器上存放和传输。

l         当远程存储文件时，避免在同一个连接上进行流入和流出的传输，为每个任务使用独立的接口。

l         不要从HTTP源来重新获取数据。只使用HTTP来进行动态播放列表的处理和获取。

 

 

高级 FF/RW

包含在Windows Media Server 2003 SP1里面的WMS的升级包里面包含高级FF/RW 媒体程序插件，它能够帮助减轻在用户提交快进或者快退请求时所产生的数据源瓶颈。这种插件在高比特率传输的场景的时候非常有效，比如在IPTV系统中进行点播传输。使用这个插件，内容提供方需要将文件在多个FF/RW比率上进行编码。然后这些文件这些文件才能在用户以欺骗模式发送请求的时候被访问。更多的信息，请参阅WMS的帮助文件中'理解高级FF/RW'一节。

 

    有这样一个案例，一个用户以普通的速度播放60s，然后以5倍的速度快进60s，最后恢复普通速度回放60s。下面的图显示了WMServer.exe 进程的I/O Read Bytes/sec的数据情况。

注意到使用高级FF/RW的时候，byte read要明显的低。当很多用户同时使用快进模式的时候，此插件能够很大程度上减少后端数据源的传输。

 

带宽

造成带宽瓶颈的两个主要的方面是服务器网卡的总体容量和服务器之间、服务器和用户之间的网络拓扑和容量。本文不讨论第二个方面，因为大部分的变动的原因超出了WMS的控制范围。

 

两种最常见的网卡的传输速度为100Mbps和1Gbps。在硬件的支持下，WMS能够使用网卡95%容量。

 

使用典型的服务器配置，使用一小部分CPU资源WMS就能够达到单个100Mbps网卡的极限。因此，本文重点会放在使用1Gbps的网卡所获得的性能测试结果上，而不会讨论使用一个或者多个100Mbps的网卡的服务器配置。

 

为了使用WMS获得最大的全局吞吐量，我们推荐使用1Gbps的网卡。使用1Gbps的网卡能得到非常好的结果，可以单个服务器的吞吐量水平达到960Mbps。当在硬件S1和S2上使用2个或2个以上的网卡，CPU的使用率便成为了限制因素。尽管如此，在性能测试中，当使用2个1Gbps的网卡的时候，WMS能够达到高于1.3Gbps的吞吐量水平。

 

计算器"Windows Media Services"Current Late Send Rate是评估网络瓶颈的相关的性能计数器。每当WMS发送的数据包比预定的发送时间延迟最少1.5s，WMS便报告一次late send。Late read可能由于可用的带宽不能满足所有的用户，也可能处理器时间周期的短缺，也可能是原始的数据源的原因。第二和第三并不与网络瓶颈相关。为了确认网络瓶颈是不是late read产生的原因，需要考虑如下几个因素：

 

持续时间少于5s的late send通常表明服务器临时过载或者不能及时地获取数据源数据。客户端缓存有足够的数据以维持回放直到服务器的流媒体恢复到正常水平。通常导致系统临时过载的原因是有新的客户连接，或者大量同时的客户请求（比如搜索，快进等等）或者是在 广播时服务端播放列表的转换。如果系统过载是由于客户活动，可以考虑减少连接频率限制和保留多余的CPU资源用来处理客户请求。

 

持续超过10s的late send并且伴随较低的CPU使用率和无late read的情况通常表明有对外的网络瓶颈。检查"Windows Media Services"Current Player Allocated Bandwidth(Kbps) 和"Windows Media Services"Current Player Send Rate(Kbps) 两个性能计数器来确定是否是late send导致的网络瓶颈。分配的带宽和实际用户使用的send rate之间的差异表明客户接受数据的速度不足够快。注意网络瓶颈还可能由本地接口的限制或者发生你的网络之外的其他远程带宽限制所引起。在这种情况下，有可以遵循以下做法：增加你的网络接口和外部网络容量，限制最多的用户数量，或者增加更多的流服务器。如果你不愿意改变服务器配置，那么网络瓶颈则有可能会影响到用户回放的质量。

 

持续超过10s的late send并且伴随较低的CPU使用率和持续的late read的情况通常表明服务器不能足够快地从数据源接受数据。这是典型的数据源瓶颈。只有那些连接到收late read影响的发表点的用户才会出现回放问题。而连接到其他发表点的用户可能能够正常接受数据而不会有回放的问题。

 

   持续的late send 并伴随非常高的CPU使用率，不管有无late read，通常表明服务器上的一种或者多种资源已经耗尽。在这种情况下，很多用户会有回放的问题。这是典型到由于CPU或者内存瓶颈而引发的例子。在这个案例中，你应该减少最大用户数或者增加更多的服务器来均衡负载。

 

下面的指南能帮助你优化服务器性能和减少网络相关的问题：

l         使用Windows Media Load Simulator 9系列进行性能测试来确定你的服务器的最大容量和建立合理的限制。

l         限制总体的用户带宽为最大网络带宽的50%或者最传输普通比特率时的总体带宽的50%，或者更低。要获得限制和比特率总体带宽的更多信息请参见'限制'一节和附录B。

l         使用1Gbps的网卡来最大化你的服务器容量，多播的情况除外。

l         使用独立的网卡来传输流入和流出的数据，如果内容是远程存储的话。

l         确保网卡和网络构架支持全双工传输。

l         如果你的网络架构运行，在广播点启用多播流传输。

 

系统内存

 

有几种工具可以用来跟踪系统内存，包括Windows任务管理器和性能监控的"Process(WMServer)"Private Byte 计数器。作为一个通用原则，系统内存应该总是要比WMS的进程（WMServer.exe）使用的内存要多。理想的情况是，对于多播的情况，WMS服务器应该具备比达到目标播放效果至少多30%的内存。而对于点播的情况，我们推荐至少要多出50%，因为操作系统需要使用更多的内存来进行文件缓存操作。

 

每个用户的平均内存取决于发布点的类型和内容的编码设置，比如比特率，包大小和音频、视频流的数量。请参看附录B以获取更多有关每个用户平均内存需求的信息。根据使用模式，目标用户数，客户在不同发布流中的分布和不同的发表点类型，你要能够估算出你的流媒体系统需要多少内存。

 

如果你的服务器有足够多的物理内存，多余的内存能减少由于内存换页导致的延迟从而增加服务器整体的性能。作为流媒体的特性，WMS使用一个小的时间窗口来发送数据到所连接的用户。一个内存紧张的系统里面，当服务器处理，发送或者从数据源读取数据的时候，内存换页操作可能引起不可预料的延迟。Late send的结果通常会影响到整体的客户体验度。如果服务器有足够多的可用内存，操作系统能最大程度的利用文件缓存从而减少数据源吞吐量瓶颈造成的影响。

 

有几个决定系统内存需求的因素。举例来说，广播发布的流通常需要比点播发布的流较少的内存。连接协议同样也对整体占用的内存有影响。通常来说，基于TCP的协议需要的系统内存少于基于UDP的协议，因为WMS需要为UDP连接存储额外的信息。依据不同的比特率，WMS需要在服务器内存中存储最多10s的发送数据用来满足包的重新发送请求（当UDP包在传输过程中丢失）。需要了解更多WMS支持的协议和之间的性能区别，参见本文'协议'一节。

 

依据不同的比特率，点播用户连接需要3-10倍于广播连接的内存。另外，使用UPD协议的点播连接通常需要2-3倍使用TCP协议的连接。在实践中，一台4G内存的服务器最多支持22800个22Kbps的广播音频流和最多22000个22Kbps的点播音频流。

 

和其他的32位应用程序一样，WMS有一个内存的极限，这个极限限制了服务器最大的容量。如果WMS进程内存使用达到2G，参看本文'服务器命名空间设置'一节来获知如何减少每个用户的平均内存使用。

 

下面的指南能抱着你优化服务器性能：

l         根据目标性能水平和客户分布模式来计算所需的最优化的内存容量。

l         提供高于WMS进行广播而需的内存容量30%的系统容量。

l         提供高于WMS进行点播而需内存容量的50%的系统容量，从而最大化文件缓存容量和较少内存换页操作。

l         确保WMS使用的内存不会超过系统全部的物理内存。

l         保持WMS使用的内存水平低于2G。如果内存使用达到2G, 退出并重启WMS, 获知通过其他的服务器来均衡负载。

 

性能评估

 

本节介绍WMS 9在一系列性能和压力测试下是如何表现的。本节谈到的是一个测试参数的列表，一个对WMS极限的解释和最大化你的WMS服务器的指导。本节也同步展示了很多的图表，这些图表展示了WMS在不同的测试场景中传播22Kbps和300Kbps的数据流的可度量的测试结果。

本节包含如下的主题：

l         协议

l         比特率

l         直播VS点播流

l         快进流

l         无线

l         播放列表

l         限制

 

协议

WMS支持3种不同的unicast流媒体协议：Real Time Streaming Protocol（RTSP），Hypertext Transfer Protocol（HTTP）,和Microsoft Media Server Protocol（MMS）。RTSP和MMS均可以以TCP或者UDP的形式传输。本文使用以下的约定的名称：RTSPU(RTSPover UDP), RTSPT(RTSP over TCP), MMSU(MMS over UDP), MMST(MMS over TCP)。HTTP只能在TCP上传输。

 

WMS也支持多播流媒体。当多播的用户增加时，对服务器的性能没有明显的影响，因为多播客户是连接到流媒体而不是服务器。理论上，一个WMS服务器能够支持无限制的多播用户数。因为多播流媒体对服务器性能没有很大的影响，本文将不会讨论多播的性能问题。

 

谈到性能，协议能分为2个主要类别：基于TCP的协议（TRSPT,HTTP,MMST）和基于UDP的协议（RTSPU,MMSU）。性能测试结果表明，平均来说，WMS使用基于TCP的协议要比使用UDP的协议支持更多的流的数量。接下来的图表明了WMS在使用不同的协议的情况下所能支持的22Kbps和300Kbps的最大连接数

 

 

 

 

当一个用户连接到WMS时，URL的前缀决定了WMS使用哪种协议来进行流传输。如果URL使用默认的mms://前缀，那么用户和服务器则自动协商使用最有可能的协议。每种协议均有其优点和局限，并且一些协议比其他的协议在某些情况下更合适。举例来说，防火墙或者代理服务器可能会阻止使用某种协议来传输数据。在这种情况下，用户和服务器则自动通过协商建立起使用某种协议能通过防火墙或者代理服务器的连接。因此，我们特别建议为了更好的性能，请不要禁止任何协议的使用。

在一个典型的流媒体发布系统中，你需要支持并发的数据流通过所有的协议。因此，你能够通过评估客户在每一个特定的协议上的传输负载来哦判断服务器的容量。

 

下面的有关协议的指南能帮助你优化你的服务器性能：

l         总是使用默认的mms://前缀来作为连接的URL。这样能够使用户和服务器自行决定最有效的协议。

l         无论什么时候可能的话，使用HTTP协议。这种协议在防火墙或者代理服务器阻止RTSP和MMS协议的情况下非常有用。

l         指定一种基于TCP的协议，比如RTSPT或者HTTP，用来当服务器自己连接时候减少数据丢失，比如在一个分布式或者缓存/代理的情况下。

 

比特率

数字媒体文件的比特率，通常以Kbps来计量，会影响到WMS的性能和连接到流媒体的最大用户数。你可以用媒体文件的比特率与用户数相乘来得到流经服务器的总体数据流量。这种合计的比特率直接影响网络吞吐量，CPU使用率水平，内存‘footprint’和数据吞吐量。当媒体文件的比特率增加时，最大用户数相应减少。这两者之间的关联总是线性的。在不同的比特率条件下不同的瓶颈限制了服务器的最大容量。举例来说，当传输低比特率解码的媒体文件时，服务器通常遇到系统内存和CPU瓶颈，比如在8Kbps和22Kbps之间。另一方面，传输高比特率的媒体文件时，比如500Kbps，最大用户数通常受网络吞吐量瓶颈的限制。

 

附录B展示了一组全面的性能测试结果，它们揭示了一个WMS服务器在传输从22Kbps到1Mbps的媒体文件时的指标的度量情况。下面的图选取了一部分结果数据，比特率从22Kbps到300Kbps。这些图展示了使用RTSPU和RTSPT协议的指标对比情况，测试指标有：Processor(_Total)"% Processor Time, Process(WMServer)"Working Set, Windows, 和Windows Media Services"Current Player Send Rate（Kbps）。

 

 

 

 

复合比特率媒体文件（Mutiple-Bit-Rate）

以复合比特率编码的媒体文件导致在一个单一的文件或者流里面包含有音频，视频，或者脚步几个流的组合。每个单独的流通常都有一个不同的比特率。当用户连接到一个复合比特率（MBR）的流，播放器播放的最合适的流的集合则依据媒体内容的比特率和合适的带宽。

 

有这样一个包含3个视频流（流A—285Kbps，流B—135Kbps，流C—20Kbps）和一个音频流（流D—15Kbps）的MBR场景。当用户连接到这样的流媒体上时，用户有如下的选择：A+D(300 Kbps), B+D(150 Kbps),C+D(35 Kbps), D(15 Kbps)。举例来说，一个56 Kbps调制解调器的用户，将最有可能看到C+D流，而一个28 Kbps的用户则被限制去访问流D。

 

自动速度探测和流选择是使用MBR的关键优势。这个特点可以提供更好的用户体验而不需要为不同比特率的流搭建多个发布点。而另一方面，由于使用MBR导致的每用户内存占用和数据源负载，服务器的性能可能受到影响。这种行为发生是因为服务器需要为所有的流组合（A+B+C+D）来获取、分配内存和处理信息，而不论那个一个流被选择到。结果你的系统就会很有可能在进行MBR流传输过程遇到内存或者数据源吞吐量瓶颈。当多个用户都连接到相同的流，Windows Server 2003的文件缓存特点能够帮助缓和这种限制和使得服务器能够支持更多的流同时传输。

 

一个简单的确定服务器进行MBR流媒体传输的总体能力的方法就是考虑所有组合的流的情况下计算内存和数据源瓶颈值。

 

可变比特率媒体内容（VBR）

WMS提供对VRB流传输有限的支持。WMS使用快速缓存技术在一个固定的比特率来传输VRB流，该比特率要足够高从而避免客户端的重新缓存。因为VBR流传输的支持是在WMS 9系列平台下引入的，因此VBR流传输只能在Windows Media Player 9，WMS 9,和Windows Media codecs 9 一起组合使用的情况下进行。和使用MBR一样，你也可以通过计算在实际固定的比特率快速缓存传输数据的情况下的极限来确定大体的服务器处理能力。

 

媒体文件编码设置

编码设置，比如包大小，缓存大小，和关键帧间隔通常对于服务器和终端用来说都是透明的，因为这些设置是在媒体文件生成的时候就设置好的。即使WMS不能够控制这些设置，他们仍然会对整体的服务器能力有影响。特定的编码建议并不是本文讨论的范围，但是请在决定如何设置编码配置的时候考虑如下基本的指导意见：

l         无论什么时候可能的话，以小于1452字节的包大小来编码。这样的话，当包被组装上头文件信息后，它们将可以存放在一个单一的最大传输单元里面（1500字节）。请注意对于RTSP连接来说，这一点可能不需要，因为服务器能够自动调节包大小。

l         设定2-4s的缓存大小来减少打开延迟和搜索反应时间。请注意减少缓存时间可能会影响到编码的质量。

l         当设置编码器来进行现场流媒体传输时，设置关键帧间隔少于8s来减少在广播时候的打开延迟。

 

下面是一些基本的指南，可能在比特率方面能帮助你优化性能：

l         使用最适合你需要的比特率和解码器。举例来说，即使你的用户拥有高速连接，也不要以2Mbps的比特率来解码如果500Kbps的比特率就能满足你的质量需求。

l         当用户在以一个很大访问的比特率来访问相同的流媒体，则使用MBR进行编码从而最大化用户体验和减少设置的复杂程度。

 

 

直播VS点播

前面我们讨论过直播和点播流的性能区别。广播流通常要比点播流使用少的资源，因为广播发布点在多个用户之间共享内存和数据源，而点播发布点则必须为每个连接的用户分配内存和数据源资源。

下面的图表展示了广播发表点和点播发表点使用RTSPU和RTSPT协议传输22Kbps和300Kbps流媒体的时候计数器Processor(_Total)"% Processor Time, Process(WMServer)"Working Set, 和Windows Media Services"Current File Read Rate(Kbps)的情况。

 

 

 

 

 

 

 

从上面的图可以看出，RTSPT的表现要好于RTSPU，并且广播要比点播需求少的资源。参见附录B以获得更全面的性能测试结果，包括最大服务器容量和推荐的利用水平等细节。附录B的矩阵中覆盖了所有的协议，一般的比特率好发布点类型。同样也展示了使用了修改的命名空间设置而获得的点播性能测试结果。

 

快速流媒体

快速流媒体提供了一种即时地、一直在线的流媒体播放体验，它通过有效地减少缓冲时间和降低由于网络条件所引起的中断的可能性。快速流媒体由四个组件组成：

l         快速缓冲提供比流媒体规定的快的速率讲流媒体内容传输给客户。

l         快速开始提供比请求的比特率更高的速度来达到初始的缓存。

l         快速恢复提供一种方法，能够不需要客户请求重发而自动恢复那些丢失或者损坏的数据包。

l         快速重连允许自动在网络中断后重新连接到服务器和重新开始流传输。

 

通过快速开始，服务器以高于请求的比特率速率传输数据到客户端缓存。这使得用户更快地能够开始接收和提交内容。发布点只是在初始的缓存需求被满足后才开始以预定的比特率传输内容。相应地，建立一个快速开始的连接的网络使用率会比建立一个普通的连接要高一些的。它们之间的区别在很多用户在同一时间连接到流媒体的时候才会很明显，因为这时的连接时间相比总的流传输时间会很小。为了最大化用户对快速开始的体验，遵循下面的指导，特别是那些关系到网络和CPU的保存。

 

为了计算快速开始对特定用户场景的影响，可以使用下面的公式：

 

       这里

 

 

举例来说，通过56Kbps的调制解调器连接来传输电台流媒体。假设56Kbps的调制解调器能够达到大概45Kbps的的吞吐量，假设音频内容是以22Kbps速率解码，那么缓存的时间将会从5s（使用传统的流播放）减少到2.4s（使用快速开始）。如果是使用700Kbps的DSL连接，那么缓存时间将会更小，大概15ms。在这两个案例里面，使用快速开始功能的用户体验将比不启用快速开始功能的要好很多。

 

下面的图显示了当用户连接到一个300Kbps的广播流时计数器Processor（_Total）"% Processor Time 和Windows Media Services"Current Player Send Rate(Kpbs)的表现。开始时，没用客户连接到流媒体，8s后，180个用户同时连接并保持连接，20s后另外180个用户连接到该流媒体。

 

在一个图里面，无论是否启用快速开始，当客户连接的时候，CPU的占用水平会短暂地增长。第二个图显示网络占用水平达到稳定的所期望的水平前维持一段时间的高于一般的水平。网络占用量的峰值为持续几秒，如果几个同化同时连接到流媒体的话。对单个连接的影响通常会更小和持续小于1s。

 

 

 

 

快速缓存提供一种方法可以使得将内容以快于特定的流媒体速率的速度传输。举例来说，当快速缓存启用的话，服务器能够以500Kbps的速率传输一个100Kbps的数据流。WMS播放器仍然会以原来特定的速率播放流，但是播放器能够在播放前缓存一大部分内容。快速缓存只工作在点播流。使用快速缓存会影响到性能和减少同时连接的最大用户数，同是数据源和网络带宽使用率也会增加。从性能的观点来看，如果使用快速缓存来以500Kbps的速率传输100Kbps的流媒体所需要的系统和网络资源将和不使用快速缓存来传输500Kbps所需求的一样多。

 

尽管快速缓存可能需要更多的每用户资源使用量，但是这种使用量会随时间而减少，因为一个快速缓存的客户连接持续的时间只是一个非快速缓存连接的一小部分。举例来说，以500Kbps来传输一个2分钟，100Kbps的片段将会传输30s，在真实时间里，相同的流媒体传输会需要2分钟的网络使用。通过一段特定的时间，从你的服务器传输的总体的数据量会是一样的，无论是否启用了快速缓存。不管怎么说，仍然极力推荐你启用快速缓存功能，因为它使得连接根据时候网络带宽的波动，从而提供更好的用户体验。

 

下面图展示了不使用快速缓存向100个客户传输2分钟，100Kbps的流和使用快速缓存传输以5倍的速率传输同样的流媒体的计数器的不同表现。在第一个图里面，在用户量很小的时候，CPU占用率（"Processor(_Total)% Processor Time）的区别是很小的。第二个图显示，当快速开始启用时，总体的吞吐量（"Windows Media Service"Current Player Send Rate(Kbps)）是大概5倍和持续时间只有不使用快速缓存的时间的20%。第3个图显示使用快速缓存的客户（"Windows Media Service"Current Streaming Player）结束流传输内容和从服务器断开的速度会更快一些。

 

 

 

 

 

下面的指南能够帮你优化使用快速流媒体的时候的性能：

不要改变默认的快速流媒体设置。他们被配置为提供最可能最好的用户体验。

增加默认的Fast Start bandwidth per player(Kpbs)限制值，当在局域网环境流传输高比特率的内容（700Kbps或者更高）。使用5倍于目标内容比特率的值作为基线值。

 

 

 

无线

你可以使用WMS快速恢复功能来提高终端用户中无线场景中的用户体验。为使用快速恢复，你必须启用发布点上启用向前错误修正功能（FEC）。FEC是一种普遍使用的方法，用来保持传输中不稳定或者慢的网络连接上的数据的完整性。当FEC启用后，服务器会发送出多余的数据，这些数据用来重建那些可能中传输到客户端时丢失的数据包。这些冗余的数据包可以使得客户端重组原来的传输数据，即使有很大一部分数据包丢失。服务器根据连接过程中由客户端提交的一些参数来获得这些冗余的数据包。无线传输的支持只有当客户端与服务器端连接使用RTSPU协议的时候才工作。

 

使用FEC的无线流媒体传输会对CPU性能、内存占用和网络占用有影响。这些超出的影响的度量取决于客户端提交的参数。测试结果显示，使用默认的服务器命名空间的配置，即使用高的恢复率，设置50%的FEC(举例来说，WMFecSpan=4, WMFecPktsPerSpan=2 & WMThinning=0) ，会有对系统资源有以下的影响。

 

l         最大的客户端数量减少40%

l         网络占用增加50%

l         平均每个用户内存占用内存增加30%到70%之间

 

增加的资源占用只有当客户端具体设定FEC参数的时候才发生。简单地在发布点启用无线支持并不会导致任何明显的性能降低。附录B提供来更详细的有关服务器性能中典型的FEC比特率（32"64"128Kbps）上的细节。

 

下面的指南可能帮助你优化服务器性能，当使用无线网络传输流媒体的时候：

l         只有当客户端需要FEC的时候启用无线支持。

l         决定采用尽可能低的FEC设置来保证必须的恢复速率，并据此来配置相关设置。

l         使用高于需要的设置可能会对系统产生不需要的要求。

l         使用有四个或者更多处理器的高性能服务器来支持由于无线流媒体传输而增长的CPU和内存占用的需求。

如果所有的连接到你的服务器的客户都准备使用FEC，那么通过降低MaxResendBufferSizeSecs的命名空间的设置为0来禁掉UDP重发功能。这种改变降低了分配给每个用户的内存。更多的信息，参见'服务器命名空间'章节。

 

 

播放列表

 

播放列表提供了一种方法，把多更数字媒体的片段组织到一个单一的列表里面。WMS同时支持客户端的播放列表和服务器端的播放列表。客户端的播放列表通常有播放者或者web脚本创建并被保存为.asx为扩展名的WMS文件。服务端的播放列表通常有内容的制作者、服务器管理员或者web页面脚本来创建并被保存为.wsx扩展名的WMS文件。

 

两种类型的播放列表都会影响服务器性能和资源占用。对服务器最有可能产生影响是当客户端中播放列表元素之间传输的时候。WMS和客户端必须在每次播放列表从一个元素切换到下一个元素的时候对新的流媒体传输设置进行协商。这种类型操作的花销等同于一个新的客户端连接。而当服务器从一个播放列表入口开始流媒体播放时，对服务器端的性能没有明显的不同。

 

当流媒体播放列表的时候，在发布点类型和服务容量之间有一种很强的联系。当播放列表是从一个点播发布点进行流媒体的时候，客户端的操作都是依时开展的。因为不可能很多客户端在同一时间连接到发布点，像播放列表传输这种消耗资源的操作也在不同的时间点上发生。当播放列表上从一个广播发布点进行流媒体的时候，相反，传输几乎是同时发生的。作为结果，服务器的CPU性能占用会中广播过程中明显增加，因为由于播放列表传输，更多的客户请求需要来处理。

 

下面的图表揭示了"Porcessor (_Total)"% Processor Time, System"Context Switches/sec &"Windows Media Service"Current Player Send Rate(Kbps) 等性能计数器中播放列表传输中的影响。在这个例子中，流媒体使用RTSPT协议传输到1000个广播客户。这些图显示了在3段22Kbps，60s播放列表元素中传输的2个转换的过程。

 

 

 

 

 

 

下面的指南可能会帮助你优化服务器，当使用客户端或者服务器播放列表的时候。

l         无论什么时候可能的话，使用小的服务器端播放列表（50个元素或更少）来进行点播，从而减少每个用的内存占用。

 

l         如果你计划中广播的时候使用包含多个元素的播放列表，限制全部的用户不超过最大数的20%。

 

l         将.wsx文件存储到你的本地文件系统来减少客户端连接的延迟，因为如果服务器需要从HTTP资源来获取这些文件。

 

 

限制

 

你可以使用限制来得到你的WMS服务器的性能边界。通过调整限制值，你能够确保你的传输不会超过你的服务器、网络、听众的容量。极力建议你在发布WMS到生产环境的之前评估系统的容量并对服务器限制设置合适的值。你可以根据具体的需要中服务器级别和发布点级别来设置限制。

 

下面是一些你能够中WMS中配置的限制参数：

l         限制播放用户连接。 极力建议你将这个限制值设置为一个合适的值，而不要设置为默认值（Unlimited）。根据你的硬件配置，流传输场景和系统需求，设置一个最大播放用户连接数。

l         限制外部分发服务器连接数。确定你的系统需要多少分发服务器并合理设置该限制值。不要保留该值为（Unlimited）。

l         限制合计用户带宽（Kbps）和限制合计的外部分发带宽（Kbps）。总是设置这些限制值为100%。你不应该使用这些限制值来保持你的网络占用水平低于50%。设置这些值过低的话会影响到网络占用水平和快速流传输的功能性。你应该通过限制最大用户连接数来使网络占用水平保持在50%以下。

l         限制每用户每流播放的带宽和限制每外部分发流的带宽。你能够使用这些限制的默认值。你也能设置这些值等于每用户快速开始带宽或者最高流传输比特率，这个值可能会高一些。

l         限制连接速率（每秒）。设置这个值小于或者等于50用户每秒。该限制帮助用来确保现有的连接不会受到不利的影响，当有大量新客户连接到服务器的时候。它同样也保证用户连接到流媒体时候获得比较好的体验。性能测试结果显示设置该限制值为50个客户每秒能够在大多少情况下提供最优的效果。

l         限制进来的带宽。确定你的系统需要的进来带宽的容量并合理设置该限制值。不要保留为Unlimited。

l         限制用户超时暂停（s）和限制连接确认（s）。你可以使用这些限制的默认值。更多的有关这些限制的信息，请参阅WMS帮助文件。

l         限制每用户快速开始带宽。该值只能设置在发布点级别。你可以使用默认值。当中本地局域网传输高比特率的内容时，你才能够增加该限制值。

l         限制快速缓存内容发布率。该值只能设置在发布点级别。你可以使用默认值。如果服务器由于大量并发的用户而超载时候你应该减少该值，在点播的情况下。

 

高级调优

TCP/IP 注册表键

Windows Server 2003使用FastSendDatagramThreshold注册表键来决定一个数据包在发生操作中是应该通过快速I/O路径还是应该被缓存。快速I/O意味着服务器绕过了I/O子系统并直接拷贝到网卡的缓存。

 

FastSendDatagramThreshold的默认值上1024。如果数据包的数量超过这个值，额外的操作就不可少了。结果是，CPU占用和内容切换增加，同时服务器能够支持的并发最大用户数减少。性能测试结果显示调高这个默认的初始值能够改进服务器性能。

 

通常，只有高比特率的流媒体才会受到这个值改变的影响。大于1024比特的包通常会出现中比特率高于100Kbps的内容中。改变该值一个副作用就是会导致分配给服务器的非分页内存池的增加。该变化不会引起任何明显的问题。

 

参考附录E以获得对FastSendDatagramThreshold 键设置更深入的信息。

 

注意：不正确的编辑注册表会严重损害你的系统。编辑你的注册表之前应该备份电脑上任何有价值的数据。

 

服务器命名空间设置

 

WMS在默认的情况下已经被配置中典型的情景下能够达到最优的性能。但是，在某种条件下，你可能会被要求来改变一些命名空间的设置来配合某些内存受限的情况。改变命名空间设置的首要原因是防止服务器耗尽内存地址空间，当你使用拥有大于2GB系统内存的高性能硬的时候，这种情况会发生。改变命名空间设置也能够减少点播受限系统的内存瓶颈。通常，每一个32位的应用程序被限制使用最多4GB内存——2GB分配给用户模式内存，另外2GB分配给核心模式操作。当WMS进程（WMServer.exe）达到2Gb内存的限制，他可能将不能分配内存给额外的客户连接。即使服务器只能够分配2GB的用户模式内存，你仍应该考虑本文'系统内存'章节提到的一些建议。高度推荐加多内存给你的服务器。因为核心可能会分配多余的内存给不同的系统操作，比如文件缓存。

 

因为WMS已经被配置最优化的性能，下面的改变可能会对服务器性能产生负面影响：

 

l         增加每秒读操作的数量。这个值的改变可能会减少服务器的整体性能，因为服务器可能需要每秒大量的数据源读操作并且数据源读操作的大小可能会减少。

 

减少UDP重发缓存。如果你减少这个值，服务器保持的用来确认重发的数据也会减少。因此，通过高度等待网络由UDP连接到服务器的客户端可能会受很大的影响。

 

我们推荐在弄清改变对服务器整体性能和终端用户体验的影响前不要对服务器命名空间做改变。请注意下面的设置上相关联的，意思是说实际的内部缓存的大小和每个客户占用内存的大小可能不精确的与具体的值相等。每用户占用内存的多少取决于服务器内部参数的组合。

 

你能够使用下面的配置设置来减少分配给每个用户的内存，尤其是服务器遇到内存瓶颈的时候。参考附录B来获取如何进行变更。

 

l         OptimalBufferSizeInMSecsOnDemand 定义最大缓存大小，单位是毫秒，分配给点播发布点的每个连接。

最小设置=0X3E8(1000ms)

默认"最大设置=0X2710(10000ms)

<node

name="OptimalBufferSizeInMSecsOnDemand" opcode="create" type="int32" value="HEX_VALUE_HERE"

/>

 

l         MaxBufferSizeInBytes 定义最大缓存大小，单位是字节，分配给任何发布点的每个连接。

 

最小设置=0X200(512bytes)

默认"最大设置=0X40000(256Kbytes)

<node

name="MaxBufferSizeInBytes" opcode="create" type="int32" value="_HEX_VALUE_HERE"

/>

 

l         MaxResendBufferSizeInMSecs 定义最大缓存大小，单位是毫秒，分配给UDP重发操作的每个连接。

 

最小设置=0X0（0ms）

默认"最大设置=0X2710（10000ms）

<node

name="MaxResendBufferSizeInMSecs" opcode="create" type="int32" value="0x2710"/>

 

请使用下面的表作为服务器配置的指南，尤其是当你的目标听众使用低速的连接（典型是使用拨号连接，速度为10Kbps到40Kbps）

 

Namespace value	Range
OptimalBufferSizeInMSecsOnDemand	0x7D0 - 0xBB8
MaxBufferSizeInBytes	0x2000 - 0x4000
MaxResendBufferSizeInMSecs	0x7D0 - 0xBB8

 

请使用下面的表作为服务器配置的指南，尤其是当你的目标听众使用高速的连接（典型是使用宽带连接，速度为100Kbps到400Kbps）

 

Namespace value	Range
OptimalBufferSizeInMSecsOnDemand	0xFA0 - 0x1F40
MaxBufferSizeInBytes	0x8000 - 0x10000
MaxResendBufferSizeInMSecs	0x1388 - 0x1B58

 

如果你的目标听众使用500Kbps或者更高的速率连接到服务器，那么则不必改变任何命名空间配置。在这种情况下，其他的系统资源将会在服务器遇到内存瓶颈问题前就耗尽。

 

 

Appendix D: Changing Namespace Buffer Settings

Caution   Before you edit the namespace, verify that you have a backup copy of the configuration file that you can restore if a problem occurs. If you edit the namespace incorrectly, you may be required to reinstall any product that uses the Windows Media Services namespace settings. Microsoft cannot guarantee that problems resulting from incorrectly editing the namespace can be solved.

Stop Windows Media Services (run the net stop wmserver command).

Change to the directory where the namespace file is located (%SystemRoot%"System32"Windows Media"Server).

Open the ServerNamespace.xml file in a text editor, such as Notepad.

Locate the Other node in the namespace.

Add the PacketPump sub-node under the Other node after any existing sub-nodes:

<node name="PacketPump" opcode="create" > ... </node> <!—PacketPump -->

Add the following values to the PacketPump sub-node to modify the default values. If you do not make any changes, the default value is used. See to the "Advanced Tuning" section of this paper for appropriate values recommendations.

<node name="OptimalBufferSizeInMSecsOnDemand" opcode="create" type="int32" value="0x1f40" />

 

<node name="MaxBufferSizeInBytes" opcode="create" type="int32" value="0x10000" />

 

<node name="MaxResendBufferSizeInMSecs" opcode="create" type="int32" value="0x2710" />

Restart Windows Media Services (run the net start wmserver command).

The following is an example of the code that you can add to the ServerNamespace.xml file:

<node name="Other" opcode="create" >

    <node name="Client Upgrade" opcode="create" >

    ...

    </node> <!-- Client Upgrade -->

    <node name="PacketPump" opcode="create" >

        <node name="OptimalBufferSizeInMSecsOnDemand" opcode="create" type="int32" value="0x1f40" />

        <node name="MaxBufferSizeInBytes" opcode="create" type="int32" value="0x10000" />

        <node name="MaxResendBufferSizeInMSecs" opcode="create" type="int32" value="0x2710" />

    </node> <!-- PacketPump -->

</node> <!-- Other -->

 

Appendix E: Registry Keys

Caution   Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

FastSendDatagramThreshold

HKEY_LOCAL_MACHINE"System"CurrentControlSet"Services"AFD"Parameters"

FastSendDatagramThreshold. This setting controls how datagrams are sent to the client computers. Datagrams smaller than the default go through the fast I/O path or are buffered during the send process. Larger ones are stored until the datagram is actually sent. Fast I/O means that the server copies data and bypasses the I/O subsystem instead of mapping memory and going through the I/O subsystem.

Set this key to a value that is larger than the packet size of the highest bit rate stream the server will deliver.

Type: DWORD

Default: 1024

Recommended value: 1500

 

Appendix F: Performance Counters

The following performance counters were used to collect performance and scalability information during Windows Media Services tests. The sample rate was set to 1 second.

 

Processor:

"Processor(_Total)"% Processor Time

"Processor(_Total)"Interrupts/sec  

 

Windows Media Services counters:

"Windows Media Services"Current Streaming Players  

"Windows Media Services"Current Connected Players  

"Windows Media Services"Current Late Send Rate 

"Windows Media Services"Current Late Read Rate 

"Windows Media Services"Current Connection Queue Length

"Windows Media Services"Current Connection Rate

"Windows Media Services"Current File Read Rate (Kbps)  

"Windows Media Services"Current Player Allocated Bandwidth (Kbps)  

"Windows Media Services"Current Player Send Rate (Kbps)

"Windows Media Services"Current UDP Resend Requests Rate   

"Windows Media Services"Current UDP Resends Sent Rate  

 

Windows Media Services process counters:

"Process(WMServer)"% Privileged Time   

"Process(WMServer)"% Processor Time

"Process(WMServer)"% User Time 

"Process(WMServer)"Handle Count

"Process(WMServer)"Page Faults/sec 

"Process(WMServer)"Page File Bytes 

"Process(WMServer)"Private Bytes   

"Process(WMServer)"Working Set 

"Process(WMServer)"Pool Nonpaged Bytes 

"Process(WMServer)"Pool Paged Bytes

"Process(WMServer)"Virtual Bytes

 

System counters:

"System"Context Switches/sec   

 

System memory counters:

"Memory"Page Faults/sec

"Memory"Cache Bytes

"Memory"Committed Bytes

"Memory"Available Bytes

 

Physical disk counters:

"PhysicalDisk(_Total)"% Disk Time  

"PhysicalDisk(_Total)"Current Disk Queue Length

"PhysicalDisk(_Total)"Disk Bytes/sec   

"PhysicalDisk(_Total)"Disk Read Bytes/sec  

 

Network interface counters:

"Network Interface(*)"Output Queue Length  

"Network Interface(*)"Bytes Sent/sec   

"Network Interface(*)"Packets Sent/sec 

"Network Interface(*)"Bytes Received/sec   

"Network Interface(*)"Packets Received/sec 

"Network Interface(*)"Packets/sec

 

Remote file systems – NTB connections (NetBIOS over TCP/IP):

"NBT Connection(Total)"Bytes Received/sec

"NBT Connection(Total)"Bytes Sent/sec

"NBT Connection(Total)"Bytes Total/sec

 

本文PDF格式下载地址：中午简体版本：https://files.cnblogs.com/木虚/优化Microsoft_Windows_Media_Services_9.pdf
                                    英文原版：
 https://files.cnblogs.com/木虚/Optimizing_Microsoft_Windows_Media_Services_9_EN.pdf