优化WMS9

优化 Microsoft Windows Media Services 9 Series

发布日期： 1/7/2005 | 更新日期： 1/7/2005

Alexandre Ferreira
Microsoft New Media Platforms Division

适用于：

Microsoft® Windows Media® Services 9 Series

本页内容

	简介
	基本原则
	Windows Media Services 4.1 版与 Windows Media Services 9 Series
	瓶颈
	性能评估
	高级优化
	附录A：实验设置描述
	附录 B：测试配置文件
	附录 C：测试内容规范
	附录 D：更改命名空间缓冲设置
	附录 E：注册表项
	附录 F：性能计数器
	更多信息

简介

本文提供 Microsoft® Windows Media® Services 9 Series 的性能和可伸缩性的技术概述。它描述了 Windows Media Services 的常见性能问题、局限性和性能监控技术。它还提供了在受控实验环境下进行的一组性能测试的测试结果。

建议您将本文档所提供的信息当作一种原则加以对待。性能测试结果是基于特定硬件配置的，它是实际情景的一种简化。流媒体系统的实际能力取决于多种因素，包括网络拓扑、用户使用模式、硬件配置和软件配置。根据本文的原则和性能信息，您应该能够设计服务器、对它进行很好地优化并使它的能力达到最大，从而实现个人环境的最佳结果。

本文包括以下主题：

•	基本原则。提供一些在设置流媒体系统时应该遵循的简单原则。
•	Windows Media Services 4.1版与 Windows Media Services 9 Series。比较两种版本的 Windows Media Services 的特性和性能。
•	瓶颈。提供常见的服务器性能问题可能的原因和解决方法。
•	性能评估。介绍在一系列性能和压力测试下 Windows Media Services 9 Series 的表现。
•	高级优化。提供有关 Windows Media Services 其他优化技术的信息。
•	附录。Windows Media Services 实验测试的详细配置和结果。
•	更多信息。提供有关其他资源的信息。

返回页首

基本原则

为了保证用户的最佳体验，请考虑以下的基本原则：

•	将用户的总数限制在负载测试中所达到的最大用户容量的 50%。
•	确保网络的整体使用率少于最大网络接口容量的 50%，或者少于最常见比特率下最大吞吐能力的 50%。
•	确保服务器有足够的可用内存来达到期望的性能水平。
•	如果可能，对流式处理使用专用的计算机。当对内容进行流式处理时，避免在使用的服务器上运行其他很占 CPU 的服务，例如 Internet 信息服务 (IIS) 或 Microsoft SQL Server™。

返回页首

Windows Media Services 4.1 版与 Windows Media Services 9 Series

与以前的版本 Windows Media Services 4.1 版相比， Windows Media Services 9 Series 在性能上有了很大的改进。以下列表包含了 Windows Media Services 9 Series 促进性能提高的一些特性：

•	新对象模型和可扩展插件体系结构。
•	经过改进的 I/O 和线程模型。
•	由快速流提供的经过改进的用户体验。快速流由四个组件组成：快速启动、快速缓存、快速重连接和快速恢复。
•	由于检索的数据块更大，所以搜索硬盘的操作更少。
•	一般流情景中的并发用户数增加。
•	使用 Microsoft Windows® Server 2003 操作系统的文件缓冲能力在内存中缓存频繁访问的内容。
•	通过用户数据报协议 (UDP) 传输使得包恢复速率更快。
•	支持实时流协议 (RTSP)。
•	经过改进的负载仿真工具 (Windows Media Load Simulator 9 Series)。

以下图表总结了与 Windows 2000 中的 Windows Media Services 4.1 版相比， Windows Server 2003 中的 Windows Media Services 9 Series 性能的提升。第一组数据柱表示两个平台中最大广播用户数比较。第二组数据柱表示对于设有三个 Ultra SCSI 3 15000 转速硬盘的 RAID 0 硬件环境，最大请求用户数比较。第三组数据柱表示对于单个 Ultra SCSI 3 15000 转速硬盘，最大请求用户数比较。

调制解调器/拨号

图 1. 调制解调器/拨号连接的版本比较

DSL/宽带

图 2. DSL/宽带连接的版本比较

Intranet

图 3. Intranet 连接的版本比较

返回页首

瓶颈

当一个过程或活动的一部分比其他部分慢或阻止其他部分的进行时，就会产生瓶颈，从而阻碍整个过程或影响整体性能。Windows Media Services 系统中最常见的瓶颈是处理器 (CPU) 能力、数据源吞吐量、传出的网络带宽和系统内存。CPU 使用率和系统内存瓶颈通常比数据源吞吐量和网络带宽限制更容易识别。

要使 Windows Media 服务器能力最大化并改善最终用户的体验，识别、消除系统中的所有瓶颈或使其影响降至最低程度是至关重要的。

处理器 (CPU) 能力

系统管理员倾向于认为只要 CPU 使用率不达到 100%，系统状态就是良好的。遗憾的是，这种假设并不总是正确的。例如，在几种情况下即使 CPU 的利用水平很低，服务器也不能接受超额负载。

有其他几种类型的瓶颈不是由高 CPU 使用率造成的。这些瓶颈会严重降低最终用户的体验，但不影响服务器的 CPU 利用水平。通常，系统内存瓶颈会因内存页面操作而导致 CPU 的使用率接近 100%。而另一方面，网络带宽和数据源吞吐量瓶颈通常不会影响 CPU 的平均利用水平。

可以使用几种不同的程序和工具监视 CPU 使用率，包括：

•	用于 Microsoft 管理控制台 (MMC) 的 Windows Media Services 管理单元。该管理单元在详细信息窗格的 Monitor 选项卡中提供系统 CPU 使用率信息。
•	Windows Task Manager。
•	Performance Monitor。\Processor(*)\% Processor Time 计数器提供有关 CPU 使用率的更加详细的信息，例如图表和历史记录信息。

确定流媒体系统的正确硬件需求、容量和 CPU 能力十分重要。平均 CPU 使用率主要取决于用户执行的操作，例如连接流、对内容进行流式处理、更改播放列表条目、快速转发、搜索或者提交日志条目。

作为一般原则，平均 CPU 使用率不应该超过 25%，在特定比特率下，并发用户数应该在最大服务器容量的 50% 以下。虽然这条原则看起来有些保守，但是它是根据以下事实确定的：内部服务器操作所占用的 CPU 变化范围很大。例如，假设服务器对几千个稳定的客户端进行广播。根据所使用的比特率和服务器，平均 CPU 使用率一般都在 20% 以下。如果有几百个客户端同时试图连接到服务器或切换到不同的播放列表条目，则服务器的 CPU 使用率可能在几秒钟的时间内蹿升到很高的水平。一般情况下，向多个客户端流式传输需要占用的服务器 CPU 比处理单个客户端请求所占用的要少。因此，保持 CPU 平均负载低于 25% 并不会导致最大流用户数明显的降低。其余 75% 的服务器 CPU 能力可用来处理更占用 CPU 的用户请求，从而使响应时间最短，用户体验最大化。快速流和搜索操作是很占 CPU 的操作的两个例子，它们可以在额外的空闲 CPU 周期内得到处理。

如果您发现服务器的平均 CPU 使用率暂时高于推荐值，则应该：

•	避免服务器端的实时播放列表操作。
•	降低 Connection rate (per second) 限制。
•	降低 Fast Start bandwidth per player 限制。

从长远来看，应该考虑增加硬件能力以便降低平均 CPU 使用率水平并为用户提供更高质量的服务。

处理器数量

Windows Media Services 9 Series 大多数操作都是 I/O 操作。因此，增加处理器的数量并不一定能提升服务器的处理能力。内部总线布局、总线速度、网络接口总线位置、不同处理器之间的中断处理分布和数据源的吞吐能力等其他因素都会对整体性能产生很大的影响。

当 Windows Media 服务器使用 1 千兆比特每秒 (Gbps) 的网络适配器时，可伸缩性测试表明双物理处理器系统在大多数情况下都能得到最好的结果。当服务器使用 100 兆比特每秒 (Mbps) 的网络适配器时，测试表明单处理器服务器可以处理大多数情况下的负载。当您通过无线网络流式传输和使用很占 CPU 的插件时，推荐您使用具有四个以上处理器的计算机。

以下图表显示了在启用 1、2、4 和 8 个处理器的计算机上运行时，Windows Media Services 可以提供的 22 千比特每秒 (Kbps) 和 300 Kbps RTSPU 流的最大数目。粗略看来，随着处理器数目线性增长，所连接的用户数以指数级增长。这种情况主要是由 I/O 资源限制造成的。由于 I/O 限制，额外的处理能力不能完全发挥出来。有关本测试所使用的八处理器服务器的具体硬件信息（参考硬件 S3），请参考附录 A。

图 4. 22 Kbps 流的最大数目

图 5. 300 Kbps 流的最大数目

请按照以下原则实现涉及处理器能力的最佳服务器性能：

•	将平均 CPU 利用水平限制在全部处理器能力的 25% 以下。
•	当向多个客户端流式传输内容时，避免运行很占 CPU 的操作。
•	如果 CPU 的使用率在正常使用率水平以上，则应该尽可能多地退出程序，包括用于 Microsoft 管理控制台 (MMC) 的 Windows Media Services 管理单元。

数据源吞吐量

通过内置插件和非 Microsoft 数据源插件，Windows Media Services 9 Series 可以支持各种来源的数据流媒体。默认安装的 Windows Media Services 包含一组插件，它们可以提供对网络上的内容（来自其他 Windows Media 服务器或编码器的流）、通过 HTTP 下载的内容和存储在本地或远程文件系统上的文件数据源的访问。

为了保证良好的用户体验（而不用考虑数据源），请确保服务器和数据源之间的连接能够维持要求的数据传输速率。数据源可以像存储在本地硬盘上的流一样简单。比较复杂的数据源包括从分发服务器接收的流或存储在网络附加存储 (NAS) 设备和存储区域网 (SAN) 基础结构中的流。根据数据源连接到服务器的方式（体系结构、驱动程序、协议等）的不同，最大吞吐量和对服务器 CPU 使用率的影响会有很大差别。各种解决方案的具体性能结果和它们之间的比较不在本文的讨论范围内。请与您的存储解决方案提供商协商，确定最大可接受的吞吐量及其对 CPU 使用率的影响。

在确定数据源吞吐量需求时，发布点类型是个很关键的因素。广播发布点对数据源的需求比请求发布点少。在任何特定时刻，连接到广播发布点的用户都收到同一块数据的副本。一般情况下，广播发布点检索来自数据源的一个数据实例，然后对它进行分割并发送给多个用户。请求发布点则不同，对于每个客户端连接，它都需要读取不同的数据，从而增加了数据源的负载。

有些情况下会有几个来自少数很受欢迎的文件的请求用户流内容。为了提高这种情况下的性能，内置的 WMS 文件数据源插件会利用 Windows Server 2003 操作系统的文件缓冲能力。在这种方式下，如果有几个请求用户访问相同的流，Windows Media Services 就会从服务器的缓存中检索数据，而不是从原始数据源中检索。这种方式有助于大大降低对数据源吞吐量的需求。默认情况下，当数据来源于本地 NTFS 或 FAT 文件系统时，Windows Media Services 就可以利用文件缓冲能力。根据驱动程序的实现，文件缓冲可以支持其他类型的存储系统。与您的存储解决方案提供商协商，确定他们的解决方案是否支持 Windows Server 2003 文件缓冲功能。

以下图表显示了对于使用 RTSPT 协议的 22 Kbps 和 300 Kbps 流，PhysicalDisk(_Total)\Disk Read Bytes/sec 和 Windows Media Services\Current File Read Rate ( Kbps) 计数器之间的比较（同时缩放至相同单位）。这些图表所显示的是所有用户都接收来自一个内容块的请求流的理想情况。在这种情况下，Windows Media Services 从内置的 WMS 文件数据源插件读取的信息总数会线性增长，而实际从磁盘中检索的信息量却粗略地稳定在一个很低的水平。

图 6. 使用 RTSPT 的 22 Kbps 流的比较

图 7. 使用 RTSPT 的 300 Kbps 流的比较

您可以查看多个性能计数器来诊断数据源不同层的状态。用于评估数据源瓶颈的主计数器是 Performance Monitor \Windows Media Services\Current Late Read Rate 计数器。这个计数器（可同时用于服务器和发布点级别）指明当前已完成但有延迟的读取操作的数目。您可以使用 \Windows Media Services\Current Late Read Rate 计数器（可用于发布点级别）来确定哪些特定发布点目前读取操作有延迟。如果在延长的时间段内，这些计数器的值大于 0，则表明有一个或多个发布点目前的数据源吞吐量有问题。在这样的情况下，您可以使用 \Windows Media Services\Current File Read Rate ( Kbps) 和 \Windows Media Services\Current Incoming Bandwidth ( Kbps) 计数器来确定数据传入率。根据服务器的数据源，您可以使用特定的计数器（例如 Local File System\Physical Disks、Network Data Source\Network Interface 和 Remote File Systems\NTB Connections）来确定当前这些接口进行操作的所在级别。如果您发现数据源连接所使用的一个或多个接口造成了系统瓶颈，则可以考虑对它们进行升级、添加更多的资源或者将负载分发到不同的服务器上。

数据源可以分成三组：本地缓存（在内存中）、远程缓存和无缓存。

当大多数用户传输的内容很少时，则在本地缓存（在内存中）环境下进行。将更多客户端添加到本地缓存环境通常会导致内存使用率和 CPU 使用率提高。根据所使用的数据源，这样的提高通常不会造成读取延迟。相反，服务器的 CPU 使用率会达到较高的水平，而且 \Windows Media Services\Current Late Send Rate 计数器会增加到 0 以上。其结果就是 CPU 瓶颈的典型情况，这个话题将在以下章节中更加详细地介绍。例如，大多数用户对存储在本地文件系统中的单个内容块进行流式处理这种情况就是常见的本地缓存情况。

当多个用户访问多个内容块时，则在远程缓存或无缓存环境下进行。在这样的情况下，不管内容是远程缓存还是根本无缓存，当服务器和数据源之间的连接达到吞吐量限制或数据源能力被耗尽时，都会发生读取延迟。NAS 和 SAN 基础结构是远程缓存环境的较好示例，在这两种情况下最大吞吐量是由网络或专用接口容量确定的。例如，当用户对存储在本地文件系统中的多块内容进行流式处理时就会发生无缓存环境。在这种情况下，最大吞吐量通常是由磁盘或磁盘接口容量确定的。

在有些情况下，传入的数据源连接和传出的流量共享同一网络接口。不推荐采用这种配置，因为所产生的吞吐量可能会更快地占满接口。

本文所提供的所有请求性能测试都是使用存储在本地 NTFS 文件系统中的单个流进行的。选择此本地缓存方法是为了演示 Windows Media Services 与任何数据源硬件限制无关的最大能力。在请求无缓存情况中，Windows Media Services 的能力取决于数据源的硬件配置和吞吐能力。随着客户端在多个流之间的分布范围增加，由于缓存命中率降低，所以更加依赖于数据源的能力。附录 B 包含性能测试结果列表。使用参考硬件 S1 和 S2，在大约 470 兆比特每秒 (Mbps) 的吞吐率下，Windows Media Services 能够传递 22,000 22 Kbps 的请求流。类似测试表明在大约 970 Mbps 的条件下，Windows Media Services 可以支持 990 1 Mbps 的请求流。

以下原则有助于您使数据源受限的系统中瓶颈所造成的影响最小化：

•	避免将内容存储在安装操作系统的硬盘上。
•	禁用存储内容的硬盘上的页面文件操作。
•	只要可能，就将内容存储在本地硬盘上或支持 Windows Server 2003 文件缓冲的存储系统上。
•	在多服务器环境下，如果没有限制数据量和更新频率，请将内容复制到所有服务器的本地文件系统中。如果复制数据不是个很经济的解决方案，可以将数据和流量分流到多个服务器上。
•	在远程存储内容时，避免对传入和传出的流量使用相同的连接。对每个任务使用专用的接口。
•	不要从 HTTP 源检索内容。只将 HTTP 用于动态播放列表处理和检索。

带宽

带宽瓶颈的两个主要方面是服务器网络接口的全部容量和整体网络容量/一个或多个服务器和用户之间的拓扑。本文没有讨论第二个方面，因为大多数变量不在 Windows Media Services 配置的作用范围和控制之内。

两种最常见的以太网网络适配器的连接速率分别为 100 Mbps 和 1 Gbps。根据所使用的硬件，Windows Media Services 可以达到网络适配器最大容量的 95%。

在典型的服务器配置下，Windows Media Services 只使用很小一部分 CPU 资源就可以达到单个 100 Mbps 网络适配器的限制。由于具有这样的特性，本文就只关注使用 1 Gbps 网络适配器所达到的性能结果。本文不讨论具有一个或多个 100 Mbps 网络适配器的服务器配置。

为了使 Windows Media Services 的整体吞吐量最大化，建议您使用 1 Gbps 的网络适配器。1 Gbps 的网络适配器能够产生引人注目的结果：使单服务器水平达到 960 Mbps。当采用参考硬件 S1 和 S2 并使用两个或更多 1 Gbps 网络适配器时，CPU 使用率就成了限制因素。不过在性能测试中，当使用两个 1 Gbps 的网络适配器时，Windows Media Services 达到了 1.3 Gbps 以上的吞吐量水平。

\Windows Media Services\Current Late Send Rate 计数器是评估网络瓶颈时关系最大的性能计数器。每当 Windows Media Services 发送包的时间比预定发送时间至少晚半秒时，它就会报告一次发送延迟。发送延迟可能由以下原因造成：缺少可用的带宽来满足所有的客户端请求、缺少处理器周期来按时完成所有预定操作，或者因从原始数据源读取而带来延迟。第二和第三个原因不是直接与网络瓶颈有关。为了确定是否是网络瓶颈造成发送延迟，请考虑以下因素：

•	发送延迟峰值信号持续时间等于或少于 5 秒钟通常表明服务器暂时超载或者无法及时从数据源检索数据。客户端缓冲有足够的数据可以维持播放直到服务器流传输恢复正常。造成暂时性系统过载的常见原因有：新客户端连接的加入、大量并发的客户端请求（例如搜索、快进等）以及在广播过程中某些服务器端播放列表转换。如果系统过载是由客户端活动引起的，则应该考虑降低连接速率限制，保留额外的 CPU 容量以作处理客户端请求之用。
•	如果发送延迟持续时间在 10 秒以上，同时 CPU 使用率很低而且没有读取延迟，则通常表明存在出站网络瓶颈。请检查 \Windows Media Services\Current Player Allocated Bandwidth ( Kbps) 和 \Windows Media Services\Current Player Send Rate ( Kbps) 性能计数器以确定是否是由于网络瓶颈造成发送延迟。分配的带宽与播放机实际发送速率之间若存在差值则表明客户端接收数据的速度不够快。请注意，网络瓶颈可能是由本地接口限制和/或发生在您的网络外面的其他远程带宽限制造成的。在这样的环境下面，您有以下的选择：增加网络接口和/或外部网络容量、限制播放机的最大数目，或者增加其他流服务器。如果您不更改服务器配置，网络瓶颈可能会影响用户的播放质量。
•	持续发生的发送延迟持续时间超过 10 秒钟，同时 CPU 使用率很低并且持续出现读取延迟，则通常表明服务器从一个或多个数据源接收数据的速度不够快。这是数据源瓶颈的一个典型示例。只有所连接的发布点受到读取延迟影响的用户才会有播放问题。连接到其他发布点的用户可能不会有任何播放问题，可以正常速率接收数据。
•	持续发生发送延迟，同时 CPU 使用率很高（不管有无读取延迟），则通常表明服务器中一种或多种资源耗尽。在这种情况下，很多用户都会有播放问题。这是 CPU 或内存瓶颈的典型示例。在这种情况下，您应该降低最大用户数或者增加其他服务器来分流负载。

以下原则有助于您优化服务器性能，避免与网络相关的问题：

•	使用 Windows Media Load Simulator 9 Series 进行网络负载测试，确定服务器的最大容量，并为系统建立适当的限制。
•	将播放机的总带宽限制在最大网络接口容量的 50%，或者在最常见比特流下最大总带宽的 50%（选择较低的那一个）。详细信息请参阅本文的“限制”部分，具体的比特率总带宽限制请参阅附录 B。
•	使用一个 1 Gbps 的网络适配器来使服务器容量最大化（多播的情况除外）。
•	如果内容存储在远程位置，请使用专用的网络适配器来处理传入和传出的流量。
•	确保网络适配器和网络基础结构支持全双工传输。
•	如果网络基础结构允许，请为广播发布点启用多播流。

系统内存

有几个实用工具可用来跟踪系统内存，包括 Windows Task Manager 和 Performance Monitor \Process(WMServer)\Private Bytes 计数器。作为一般原则，系统内存应该总是超过 Windows Media Services 进程 (WMServer.exe) 所使用的内存大小。对于广播情况，在理想情况下 Windows Media 服务器的内存应该比在目标使用率水平下执行时所需要的内存至少多出 30%。对于请求情况，由于操作系统可以用额外的内存来进行文件缓冲操作，所以建议使服务器的可用内存比需要的可用内存至少多 50%。

每个用户使用的平均内存取决于发布点的类型和内容中使用的编码设置，例如比特率、包大小、音频流和视频流的数目。有关每个用户需要的平均内存的更多信息，请参阅附录 B。根据使用模式、目标用户数目、客户端在不同流之间的分布情况以及发布点类型，您应该能够估计您的流媒体系统需要多少内存。

如果您的服务器有很大的物理内存，额外的内存就可以使内存页面操作引起的延迟降到最低，并提高服务器的整体性能。考虑到流媒体的性质，Windows Media Services 有一个小时间窗来将数据发送给所有连接的用户。在内存受限的系统中，当服务器处理、发送或读取来自数据源的数据时，内存页面操作会导致不可预期的延迟。产生的发送延迟通常会影响整体客户端体验。如果服务器有大量可用的系统内存，操作系统就可以最大程度地使用文件缓冲，并使数据源吞吐量瓶颈的影响降到最低程度。

服务器内存需求是由几个因素决定的。例如，来自广播发布点的流比来自请求发布点的流需要的内存要少。连接协议也会影响分配的内存总数。一般情况下，基于传输控制协议 (TCP) 的协议比基于用户数据报协议 (UDP) 的协议需要的系统内存要少，因为 Windows Media Services 要为 UDP 连接存储一些额外信息。依照比特率，为了满足当 UDP 包在传输过程中丢失时的包重新发送请求，Windows Media Services 在服务器内存中存储已发送数据达 10 秒钟。有关 Windows Media Services 支持的协议及其性能区别的更多信息，请参阅本文的“协议”部分。

依照比特率，请求用户连接比广播连接需要的内存多 3 到 10 倍。另外，使用 UDP 的请求连接比 TCP 连接需要的内存通常多 2 到 3 倍。在实际中，有 4 GB RAM 的服务器最多可以支持 22,800 22 Kbps 广播音频流和22,000 22 Kbps 请求音频流。

和其他 32 位应用程序一样，Windows Media Services 有一个内存限制，它限制了最大服务器容量。如果 Windows Media Services 进程 (WMServer.exe) 的内存使用率达到 2 GB，请参阅本文的“服务器命名空间设置”部分中关于如何降低每个用户的平均内存使用率的说明。

以下原则有助于优化服务器性能：

•	根据目标性能水平和客户端分布模式计算系统需要的最理想内存数。
•	对于广播情况，提供比目标 Windows Media Services 内存使用率水平多 30% 的系统内存。
•	对于请求情况，提供的系统内存要比目标 Windows Media Services 内存使用率水平至少多 50%，以便使文件缓冲容量最大化，并使内存页面操作的影响降到最小程度。
•	确保 Windows Media Services 内存使用率水平不超出系统中的物理内存总数。
•	保持 Windows Media Services 内存使用率水平在 2 GB 以下。如果内存使用率达到 2 GB，请退出并重新启动 Windows Media Services，或者将负载分流到其他服务器。

返回页首

性能评估

本节描述在一系列性能和压力测试下 Windows Media Services 9 Series 的表现。本节内容包括测试变量列表、Windows Media Services 的限制解释和使您的 Windows Media 服务器容量最大化的原则。本节还包括显示 22 Kbps 和 300 Kbps 流测试结果的并列图表，阐述在不同测试环境下 Windows Media Services 的可伸缩性。

协议

Windows Media Services 支持三种不同的单播流协议：实时流协议 (RTSP)、超文本传输协议 (HTTP) 和 Microsoft 媒体服务器协议 (MMS)。RTSP 和 MMS 都可以通过 TCP 或 UDP 传输运行。本文档使用以下命名约定来表示这些传输方法：RTSPU（UDP 上的 RTSP）、RTSPT（TCP 上的 RTSP）、MMSU（UDP 上的 MMS）和 MMST （TCP 上的 MMS）。HTTP 只可以通过 TCP 传输运行。

Windows Media Services 还支持多播流。随着多播用户数的增加，服务器性能并没有显著的影响，因为客户端连接的是流而不是服务器。从理论上讲，Windows Media 服务器可以处理的多播用户数目没有限制。因为多播流不会对服务器性能造成很大的影响，本文不对多播性能进行讨论。

根据性能，可以将协议分成两种主要类别：基于 TCP 的协议（RTSPT、HTTP 和 MMST）和基于 UDP 的协议（RTSPU 和 MMSU）。性能结果显示，与使用基于 UDP 协议的流相比，平均起来 Windows Media Services 可以处理更多使用基于 TCP 协议的流。以下图表显示了依据所使用的协议，Windows Media Services 可以支持的 22 Kbps 和 300 Kbps 连接的最大数量。

图 8. 每种协议支持的 22 Kbps 流的最大数目

图 9. 每种协议支持的 300 Kbps 流的最大数目

当客户端连接到 Windows Media Services 时，由 URL 前缀确定 Windows Media Services 用于流内容的协议。如果 URL 有默认的 mms:// 前缀，则播放机和服务器就会自动协商最佳的可能协议。每种协议都有优点和局限性，在某些环境下，某些协议会比其他协议更加适合。例如，防火墙或代理服务器会阻止某些协议传输数据。在这样的情况下，播放机和服务器会自动尝试使用可以穿过防火墙或代理的协议重新建立连接。因此，强烈建议您不要为了提高性能而禁用任何协议。

在典型的流媒体系统部署中，您可以支持跨所有协议的并发流。因此，您可以通过每个具体协议的平均容量来分析客户端分布，从而确定服务器容量。

以下协议原则有助于您优化服务器性能：

•	对于 URL 连接，始终使用默认的 mms:// 前缀。这可以使播放机和服务器协议最佳的可能协议。
•	只要可能就启用 HTTP 协议。当防火墙或代理服务器阻止 RTSP 和 MMS 协议时，这个协议就十分有用。
•	当进行服务器之间的连接时（例如分发或缓存/代理情景），为了使数据丢失率最小化，请指定一种基于 TCP 的协议，例如 RTSPT 或 HTTP。

比特率

数字媒体内容的比特率（通常以 Kbps 为单位）会影响 Windows Media 服务器的性能和可以连接流的最大客户端数。可以将内容的比特率和每个流所连接的用户数相乘来确定服务器的总数据流量。该总比特率直接影响到网络吞吐量、CPU 使用率水平、内存“覆盖区”和数据吞吐量。随着内容比特率的增加，最大用户数会下降。两者之间的关系并非总是线性的。内容比特率水平不同，限制最大服务器容量的瓶颈也各不相同。例如，当对以低比特率（例如在 8 Kbps 和 22 Kbps 之间）编码的内容进行流式处理时，服务器通常会遇到系统内存和 CPU 使用率瓶颈。另一方面，在对高比特率内容（例如 500 Kbps 以上的内容）进行流式处理时，最大用户数通常受网络吞吐量瓶颈限制。

附录 B 展示了一组全面的性能测试结果，它们表明当流内容的比特率在 22 Kbps 到 1 Mbps 的范围时，Windows Media 服务器性能的变化范围。以下图表显示了比特率为 22 Kbps 和 300 Kbps 的内容流的数据子集。这些图表显示了对于以下计数器，使用 RTSPU 和 RTSPT 协议的可伸缩性比较：Processor(_Total)\% Processor Time、Process(WMServer)\Working Set、Windows 和 Windows Media Services\Current Player Send Rate ( Kbps)。

图 10. 在 22 Kbps 流的条件下，使用 RTSPT 和 RTSPU 协议的可伸缩性比较

图 11. 在 300 Kbps 流的条件下，使用 RTSPT 和 RTSPU 协议的可伸缩性比较

图 12. 在 22 Kbps 流的条件下，使用 RTSPT 和 RTSPU 协议的可伸缩性比较

图 13. 在 300 Kbps 流的条件下，使用 RTSPT 和 RTSPU 协议的可伸缩性比较

图 14. 在 22 Kbps 流的条件下，使用 RTSPT 和 RTSPU 协议的可伸缩性比较

图 15. 在 300 Kbps 流的条件下，使用 RTSPT 和 RTSPU 协议的可伸缩性比较

多比特率内容

以多种比特率编码的内容导致在一个文件或流中包含几种组合音频、视频或脚本流。每个单独的流通常有不同的比特率。当用户连接到多比特率 (MBR) 流时，播放机会根据内容比特率和可用的带宽播放最合适的流集合。

请考虑一种 MBR 流情景，它具有三个视频流（流 A — 285 Kbps、流 B — 135 Kbps 和流 C — 20 Kbps）和一个音频流（流 D — 15 Kbps）。当连接到流时，用户可以有以下的选择：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=500 Kbps) 检索、分配内存和处理信息，所以会发生这种情况。因此，当对 MBR 内容进行流式处理时，系统很可能遭遇内存或数据源吞吐量瓶颈。当有多个用户连接到同一个流时，Windows Server 2003 的文件缓冲功能有助于缓解这种限制，并且可以使服务器同时处理大量流。

当使用 MBR 流时，一种确定服务器整体容量的简单方法是统计所有流组合总和的内存和数据源的瓶颈。

可变比特率内容

Windows Media Services 对可变比特率 (VBR) 流提供有限支持。Windows Media Services 使用快速缓存功能以恒定比特率传递 VBR 流，这个比特率足够高，可以避免客户端再次缓冲。因为在 Windows Media 9 Series 平台中引入了 VBR 流支持，所以只有当 Windows Media Player 9 Series、Windows Media Services 9 Series 和 Windows Media 9 Series 编码解码器（Windows Media Audio 9 Series 和 Windows Media Video 9 Series）结合使用时才可以使用 VBR 流。和 MBR 流相似，当使用 VBR 流时可以确定服务器的整体容量，方法是统计快速缓存传递数据的实际恒定比特率所引起的限制。

内容解码设置

诸如包大小、缓冲大小和关键帧间隔等编码设置对服务器和最终用户来说通常是透明的，因为这些设置是在创建内容的时候配置的。尽管这些设置 Windows Media Services 无法控制，但它们仍然会影响服务器的整体容量。具体的编码建议不在本文的讨论范围之内，但是在确定要为流内容使用哪种编码设置之前，应该考虑以下的基本原则：

•	只要可能，就采用小于 1,452 字节的包大小对内容进行编码。通过这样做，当这些包再加上一些头信息时，能够适合单个的最大传输单元 (MTU) 帧（1,500 字节）。注意，对于 RTSP 连接则没有这个必要，因为服务器会自动调整包的大小。
•	使用 2 到 4 秒之间的缓冲大小，使打开延迟和搜索响应时间降到最小。注意：减小缓冲大小可能会对编码质量产生负面影响。
•	当为实时流内容建立编码器时，使用小于 8 秒的关键帧间隔，使广播期间的打开延迟降到最小。

以下是一些基本原则，有助于您实现与比特流有关的最佳性能：

•	使用最符合用户需要的比特率和编码解码器。例如，即使用户有很高的连接速度，如果 500 Kbps 比特率能够满足质量需要，就不要以 2 Mbps 的比特率对内容进行编码。
•	当客户端访问相同流时的比特率在一个较大范围内时，使用 MBR 编码方式来使用户体验最大化并最大程度降低安装复杂性。

实时流与请求流

前面我们已经讨论了广播（实时）流和请求流之间的性能差别。广播流使用的资源比请求流少，因为广播发布点可以让多个用户共享内存和数据源资源，而请求发布点则必须为每个连接的用户获取内存和数据源资源。

下列图表说明了广播发布点和请求发布点在以下方面的区别：使用 RTSPU 和 RTSPT 协议的 22 Kbps 和 300 Kbps 流的 Processor(_Total)\% Processor Time、Process(WMServer)\Working Set 和 Windows Media Services\Current File Read Rate ( Kbps) 计数器。

图 16. 传送 22 Kbps 流内容的请求发布点和广播发布点的比较图

图 17. 传送 300 Kbps 流内容的请求发布点和广播发布点的比较

图 18. 传送 22 Kbps 流内容的请求发布点和广播发布点的比较

图 19. 传送 300 Kbps 流内容的请求发布点和广播发布点的比较

图 20. 传送 22 Kbps 流内容的请求发布点和广播发布点的比较

图 21. 传送 300 Kbps 流内容的请求发布点和广播发布点的比较

在前面的图表中可以看到，RTSPT 的适应范围比 RTSPU 广，广播发布点需要的资源比请求发布点少。要了解更全面的性能结果集，包括最大服务器容量和建议使用率水平的详细信息，请参考附录 B。附录 B 中的矩阵图涵盖了所有协议、常见的比特率和发布点类型。它还显示了使用修改过的命名空间设置而实现的请求性能结果。

快速流

快速流有效地消除缓冲时间并降低网络条件造成播放中断的可能性，从而提供一种立即播放、一直播放的流体验。快速流包括以下四个组件：

•	快速缓存提供一种向客户端流式传输内容的方式，这种方式比流所指定的数据速率更快。
•	快速启动提供一种方式来让客户端以一种比所请求内容的比特率更高的速率填充原始缓冲。
•	快速恢复提供一种方式来恢复丢失或损坏的数据包，不需要客户端请求 Windows Media 服务器重新发送数据。
•	快速重连接可以使客户端在暂时网络中断之后自动重新连接到服务器并重新启动流。

在快速启动过程中，服务器会以比所请求的内容比特率更高的速率向客户端缓冲发送数据。这可以使用户快速启动接收和呈现内容。只有当原始缓冲的需求已满足时，发布点才会以定义的比特率传送流内容。因此，建立快速启动连接时的网络使用率比建立正常连接时的网络使用率略高。只有当许多用户同时连接到流时，这种差别才能感觉得到，因为与整个流的持续时间相比，连接的持续时间非常短。为了使用户有最好的快速启动体验，请遵循本文所提出的指导原则，特别是与节约网络和 CPU 相关的指导原则。

要计算特定用户环境下快速启动的效果，请使用以下公式：

图 22. 计算快速启动效果的公式

其中：

图 23. 公式描述

例如，考虑通过 56 Kbps 调制解调器连接发送的 Internet 无线广播流。假设 56 Kbps 调制解调器产生大约 45 Kbps 的吞吐量，并假设音频内容是以 22 Kbps 编码的，则缓冲时间可以从 5 秒（使用传统的流传送方式）降到 2.4 秒（使用快速启动）。对于相同的流，采用 700 Kbps DSL 连接的缓冲时间更短，大约 15 毫秒。在这两种情况下，如果没有使用快速启动，用户体验也仍然可以更好。

以下图表显示了当用户连接到 300 Kbps 广播流时，Processor(_Total)\% Processor Time 和 Windows Media Services\Current Player Send Rate ( Kbps) 计数器的行为。开始的时候，没有客户端连接到该流。8 秒钟之后，有 180 个客户端同时连接并保持连接直到 20 秒钟之后另外一组 180 个客户端进行连接。在第一个图表中可以看到，不管使用快速启动与否，当客户端连接时 CPU 使用率水平都发生了短暂的上升。第二个图表表明网络使用率水平稳定在预期吞吐量水平之前，有一个短暂的时间高于正常水平。如果有几个客户端同时连接，网络使用高峰期通常会持续几秒钟的时间。单个连接的影响通常小了很多，并且持续不到一秒钟。

图 24. 快速启动比较

图 25. 快速启动比较

快速缓存提供一种向客户端传递内容的方式，这种方式的速率比流格式所指定的数据速率快。例如，当启用了快速缓存时，服务器可以 500 Kbps 的速率传递 100 Kbps 流。Windows Media Player 仍然以指定的数据速率呈现流，但该播放机可以在呈现前缓冲更多内容。快速缓存只作用于请求流。当数据源和网络带宽使用率提高时，使用快速缓存会影响性能并减少最大并发用户数。从性能的观点看，使用快速缓存以 500 Kbps 的速率传输 100 Kbps 流所需要的系统和网络资源相当于不使用快速缓存的 500 Kbps 流。虽然快速缓存使每个用户占用更多的资源，但是这种占用会随时间推移而减少，因为快速缓存客户端连接持续的时间只是非快速缓存连接的一小部分。例如，一个两分钟、100 Kbps 的片段流在 500 Kbps 的速率下可以在大约 30 秒钟内传送，而相同的片段流在实时条件下需要占用网络两分钟。不管是否启用快速缓存，在某个时间段内，来自服务器的数据流总量是相同的。不过强烈建议您启用快速缓存，因为它使连接更能抵抗网络带宽的波动，从而提供更好的用户体验。

以下图表显示了 100 个客户端不使用快速缓存流式传输两分钟 100 Kbps 的片段流和 100 个客户端使用快速缓冲以五倍于原始速率流式传输相同片段流之间的区别。从第一个图表可以看出，在只有少量用户的情况下，CPU 使用率 (\Processor(_Total)\% Processor Time) 的差别并不显著。第二个图表表明，当启用快速启动时，总吞吐量 (\Windows Media Services\Current Player Send Rate ( Kbps)) 高于未启用快速缓存的流的 5 倍左右，而占用时间为原来的 20%。第三个图表表明，使用快速缓存的客户端 (\Windows Media Services\Current Streaming Players) 完成流式传输内容并断开与服务器的连接的速度更快。

图 26. 快速缓存比较

图 27. 快速缓存比较

图 28. 快速缓存比较

当使用快速流时，以下原则有助于您优化性能：

•	不要更改快速流的默认设置。它们是为提供可能获得的最佳客户端体验而配置的。
•	当在 LAN 环境中流式传输高比特率的内容（700 Kbps 及以上）时，提高 Fast Start bandwidth per player ( Kbps) 的默认限制。使用目标内容比特率的 5 倍速率，将其作为基准值。

无线

您可以使用 Windows Media Services 快速恢复功能来改善无线流情况下的最终用户体验。要使用快速恢复，必须在发布点上启用前向纠错 (FEC)。FEC 是在不可靠或慢速网络连接的条件下，保持所传送数据的完整性的常见方法。当启用 FEC 时，服务器会发送额外的数据，在到达客户端之前可以使用它们来重建可能丢失的任何包。即使丢失的包数量很多，这些冗余包也可以使客户端重建初始的传送内容。服务器根据连接过程中客户端所提交的参数创建这些额外包。只有当客户端使用 RTSPU 协议连接到服务器时，才能具有无线支持。

采用 FEC 的无线流会影响 CPU 性能、内存使用率和网络使用率。增加多少开销取决于客户端提交的参数。测试表明，使用默认的服务器命名空间配置设置（也就是使用可恢复 50% 的高恢复率 FEC 设置，例如 WMFecSpan=4、WMFecPktsPerSpan=2 和 WMThinning=0）对系统资源会有以下的影响。

•	最大客户端数目减少 40% 以上。
•	网络使用率提高 50% 以上。
•	每个客户端的平均内存使用率提高 30% 到 70%。

只有当客户端在连接过程中指定 FEC 参数时才会增加资源使用率。只是在发布点级别启用无线支持并不会使性能发生明显的降低。附录 B 提供了在典型 FEC 比特率（32 Kbps、64 Kbps 和 128 Kbps）下服务器性能的详细信息。

当通过无线网络传送流时，以下原则有助于您优化服务器性能：

•	只有当客户端连接需要 FEC 时才启用无线支持。
•	确定可能达到的最低 FEC 设置来保证需要的恢复率，并根据它配置设置。使用的设置比需要的高可能会对系统提高不必要的要求。
•	使用具有四个以上处理器的高性能服务器来支持无线流对 CPU 和内存使用率的更高需求。
•	如果所有客户端都准备使用 FEC 连接到您的服务器，请禁止 UDP 重新发送，方法是将 MaxResendBufferSizeInMSecs 命名空间的设置减为零。这个更改会降低为每个用户分配的内存数。有关更多信息，请参阅本文的“服务器命名空间设置”部分。

播放列表

播放列表提供一种将多块数字媒体内容组织在一个列表中的方式。Windows Media Services 支持客户端播放列表和服务器端播放列表。客户端播放列表通常是由播放机或 Web 脚本创建的，保存为文件扩展名为 .asx 的 Windows Media 元文件，。服务器端播放列表通常是由内容提供商、服务器管理员或 Web 页面脚本创建的，保存为文件扩展名为 .wsx 的 Windows Media 元文件。

这两种类型的播放列表都会影响服务器性能和资源占用率。当客户端在不同播放列表元素间转换时，会对服务器产生直接相关的影响。每次播放列表从一个元素转换到另一个元素时，Windows Media Services 和客户端都必须协商新的流设置。这种操作的成本可以量化为客户端整个连接的一部分。而当服务器自身流式传输播放列表条目时，服务器性能并没有显著的区别。

当流式传输播放列表时，发布点类型和服务器的容量之间并没有很大的关系。当播放列表流自请求发布点时，客户端操作会随时间均化。因为许多客户端同时连接到发布点的可能性很小，所以象转换播放列表这样很占资源的操作也会及时发生在不同的发布点上。然而，当播放列表流自广播发布点时，转换通常都会同时发生。因此，在广播期间服务器的 CPU 使用率会显著提高，因为处理多个与播放列表转换相关的客户端请求需要额外的开销。

以下图表阐述了在播放列表转换期间 \Processor(_Total)\% Processor Time、System\Context Switches/sec 和 \Windows Media Services\Current Player Send Rate ( Kbps) 性能计数器的影响。在这个示例中，流通过 RTSPT 协议传递给 1,000 个广播客户端。这个图表显示了三个 22 Kbps、60 秒播放列表元素之间的两次转换。其他协议也证明有相似的行为。

图 29. 播放列表转换对性能监视器的影响

图 30. 播放列表转换对性能监视器的影响

图 31. 播放列表转换对性能监视器的影响

当使用客户端或服务器端播放列表时，以下原则可以帮助您优化服务器：

•	只要可能，就对请求发布点使用小型服务器端播放列表（50 个元素或更少），从而降低每个用户所分配的内存数。
•	如果计划在广播期间使用包含多个元素的播放列表，对于特定的比特率，将用户总数限制在最大用户数的 20% 或以下。
•	在本地文件系统中存储静态播放列表 (.wsx) 文件，使服务器从 HTTP 源检索这些文件所造成的客户端连接延迟降到最低程度。

限制

您可以使用限制来指定 Windows Media 服务器的性能界限。通过调整限制值，可以确保传输不会超出服务器、网络或观众的接受能力。强烈建议您在部署到生产环境之前先估计一下系统的容量并设置合理的服务器限制。根据您的具体需要，可以同时指定服务器级别和发布点级别的限制。

以下是一些可以在 Windows Media Services 中配置的限制：

•	限制播放机连接。强烈建议您将这个限制值从 Unlimited（默认值）更改为适合您的系统的值。根据您的硬件配置文件、流情景和系统需求建立最大播放机连接数。
•	限制传出分发连接。确定系统需要的分发服务器的数目并对该限制进行恰当地设置。不要保留为 Unlimited。
•	限制播放机总带宽 ( Kbps) 和限制传出分发总带宽 ( Kbps)。始终将这些限制设置为网络接口吞吐量限制的 100%。不应该使用这些限制使网络使用率水平保持在最大容量的 50% 以下。这些限制设置得很低可能会抑制网络使用率和快速流功能。相反，应该通过限制最大播放机连接数来使网络使用率水平维持在网络容量的 50% 以下。
•	限制每个播放机每个流的带宽 ( Kbps) 和限制每个传出分发流的带宽 (Kbps)。对于这些限制，可以使用默认值。也可以将这些限制设置为 Fast Start bandwidth per player ( Kbps) 限制的值或最高流比特率（选择较高的那一个）。
•	限制连接速率（每秒）。将这个限制设置为小于或等于每秒 50 个客户端。这个限制有助于确保当大量新客户端连接到服务器时，不会对现有的连接产生负面影响。也有助于确保当用户连接到流时可以获得可能达到的最佳体验。使用参考硬件进行的性能测试表明，将这个限制设置为每秒 50 个客户端在大多数情况下都可以得到最优的结果。
•	限制传入带宽 (Kbps)。确定系统需要的传入带宽值并恰当地设置该限制。不要保留为 Unlimited。
•	限制播放机不活动超时时间（秒）和限制连接确认时间（秒）。对于这些限制，可以使用默认值。有关这些限制的更多信息，请参阅 Windows Media Services 帮助。
•	限制每个播放机的快速启动带宽 ( Kbps)。这个值只能在发布点级别设置。对于这个限制，可以使用默认值。只有当通过局域网 (LAN) 流式传输高比特率流内容时才可以提高这个限制值。
•	限制快速缓存内容传递速率。这个值只能在发布点级别设置。对于这个限制，可以使用默认值。在请求情景中，如果服务器因大量并发用户而超载，则应该降低这个值。

返回页首

高级优化

TCP/IP 注册表项

在发送操作中，Windows Server 2003 使用 FastSendDatagramThreshold 注册表项来确定数据报应该通过快速 I/O 路径还是应该进行缓冲。快速 I/O 意味着服务器跳过 I/O 子系统，直接将数据复制到网络接口缓冲中。

FastSendDatagramThreshold 项的默认值是 1024。如果一个流中包的数量超过这个值，就需要进行额外的操作。因此，CPU 使用率和上下文切换就会增加，而服务器可以处理的最大并发客户端数目会减少。性能测试表明，将这个默认阈值设置更改为较高的值（例如 1500 字节）可以提高服务器性能。

一般情况下，更改这个项只会对高比特率流产生影响。大小超过 1024 个字节的包一般只会出现在比特率超过 100 Kbps 的内容中。更改这个项值产生的负面影响是增加了为服务器分配的非页面缓冲池的字节数。这个更改不会造成什么大的问题。

有关更改注册表中 FastSendDatagramThreshold 设置的更多信息，请参考附录E。

警告： 注册表编辑不当可能会对系统产生严重的损坏。在对注册表进行更改之前，应该先对计算机中有价值的数据进行备份。

服务器命名空间设置

默认情况下，Windows Media Services 被配置为可在典型使用率下达到最佳性能。然而在某些情况下，为了能够在特定内存限制下工作，可能需要更改一些命名空间设置。更改命名空间设置的主要原因是防止服务器内存地址空间不足，当您使用系统内存在 2GB 以上的高性能硬件时可能会出现这种情况。在请求受限的系统中，更改命名空间设置也可以使内存瓶颈的影响降到最低程度。一般情况下，每个 32 位的应用程序都被限制为最多占用 4GB 内存 — 2GB 用作用户模式内存，另外 2GB 用于内核模式操作。当 Windows Media Services 进程 (WMServer.exe) 达到 2GB 内存限制时，它就无法再为其他客户端连接分配内存。虽然服务器只能分配 2GB 用户模式内存，但您仍应该考虑本文“系统内存”部分所提出的建议。强烈建议您在服务器中添加额外的内存。内核可以使用此额外内存进行各种系统操作（例如文件缓冲）。

因为 Windows Media Services 已经配置为可能达到的最好性能，所以下列更改也许会对服务器的性能产生不利的影响：

•	增加每秒读取操作数。更改这个值可能会降低服务器的整体性能，因为服务器可能每秒钟需要读取大量数据源，而数据源读取的大小会下降。
•	减少 UDP 重新发送缓冲。如果减小这个值，服务器为确认 UDP 重新发送请求而保存的数据的数量也会减少。因此对使用 UDP 通过延迟很大的网络连接到您的服务器的客户端会有不利的影响。

建议您在更改服务器命名空间之前先明确它对服务器整体性能和最终用户体验会有什么样的影响。注意以下设置是相关的，意味着实际内部缓冲大小和每个客户端占用的内存数可能与指定的值不完全一致。每个客户端占用的内存数取决于几个内部参数的组合。

当服务器达到内存限制时，可以使用以下的配置设置来降低为每个用户分配的内存数。有关如何进行这些更改的信息，请参阅附录 B。

•	OptimalBufferSizeInMSecsOnDemand。为请求发布点定义为每个连接所分配的最大缓冲大小（以毫秒为单位）。 Minimal setting = 0x3E8 (1000 ms) Default/Maximum setting = 0x2710 (10000 ms) <node name="OptimalBufferSizeInMSecsOnDemand" opcode="create" type="int32" value="HEX_VALUE_HERE" />
•	MaxBufferSizeInBytes。为任何发布点定义为每个连接所分配的最大缓冲大小（以字节为单位）。 Minimal setting = 0x200 (512 bytes) Default/Maximum setting = 0x40000 (256 Kbytes) <node name="MaxBufferSizeInBytes" opcode="create" type="int32" value="_HEX_VALUE_HERE" />
•	MaxResendBufferSizeInMSecs。为 UDP 重新发送操作定义为每个连接所分配的最大缓冲大小（以毫秒为单位）。 Minimal setting = 0x0 (0 ms) Default/Maximum setting = 0x2710 (10000 ms) <node name="MaxResendBufferSizeInMSecs" opcode="create" type="int32" value="0x2710"/>

当您的目标观众使用低速连接（通常指从 10 Kbps 到 40 Kbps 的拨号连接速度）时，请使用下表作为服务器配置指南。

命名空间值	范围
OptimalBufferSizeInMSecsOnDemand	0x7D0 - 0xBB8
MaxBufferSizeInBytes	0x2000 - 0x4000
MaxResendBufferSizeInMSecs	0x7D0 - 0xBB8

当您的目标观众使用高速连接（通常指从 100 Kbps 到 400 Kbps 的宽带连接速度）时，请使用下表作为服务器配置指南。

命名空间值	范围
OptimalBufferSizeInMSecsOnDemand	0xFA0 - 0x1F40
MaxBufferSizeInBytes	0x8000 - 0x10000
MaxResendBufferSizeInMSecs	0x1388 - 0x1B58

如果您的目标观众使用 500 Kbps 或更高的连接速度连接到您的服务器，则就不大可能需要更改任何命名空间。在这种情况下，服务器在碰到内存限制问题之前就已经有其他系统资源被耗尽了。

返回页首

附录A：实验设置描述

Windows Media Services 9 Series 性能测试是在受控的实验环境下进行的。以下图表描述了测试过程中使用的硬件配置。

图 32. Windows Media Services 测试的实验设置

服务器硬件配置文件 1 (S1)

S1—Dell PowerEdge 2650
双 2.4 GHz Intel Xeon (HT) 处理器
400 MHz 前端总线
512 KB L2 高级传输缓存
4 GB 200 MHz DDR SDRAM
PCI-X（1 X 64 位/133 MHz）支持
具有三个 18.2GB Ultra3 SCSI 15,000 转速硬盘的双通道 (PERC 3/DC) PowerEdge Expandable RAID 控制器，版本 3
Intel PRO/1000 XF Server Adaptor（支持 64 位/133 MHz PCI-X 总线）。
Windows Server
Windows Server 2003 企业版
Windows Media Services 9 Series

服务器硬件配置文件 2 (S2)

S2—HP/Compaq ProLiant ML530 G2
双 2.4 GHz Intel Xeon (HT) 处理器
400 MHz 前端总线
512 KB L2 高级传输缓存
4 GB 200 MHz DDR SDRAM
PCI-X（1 X 64 位/133 MHz）支持
18.2 GB Ultra3 SCSI 15,000 转速硬盘
Intel PRO/1000 XF Server Adaptor（支持 64 位/133 MHz PCI-X 总线）
Windows Server 2003 企业版
Windows Media Services 9 Series

服务器硬件配置文件 3 (S3)

S3—Compaq ProLiant 8500
八个 550 MHz Intel PIII Xeon 处理器
100 MHz 前端总线
1 MB L2 缓存
8 GB 100 MHz SDRAM
PCI-X（1 X 64 位/133 MHz）支持
18.2 GB Ultra3 SCSI 10,000 转速硬盘
Intel PRO/1000 F Server Adaptor
Windows Server 2003 企业版
Windows Media Services 9 Series

客户端16 个客户端计算机

C1 C16—Dell Optiplex 240
1.5 GHz Intel Pentium 4 处理器
512 MB SDRAM
40 GB ATA100 IDE 硬盘
3Com 3C920 Integrated Fast Ethernet 10/100 或 Intel PRO/1000 F Server Adaptor
Windows Server 2003 企业版
Windows Media Load Simulator 9 Series

网络交换机：

N—Extreme Networks Summit 4

16 100 Mbps 全双工端口
6 1 Gbps 全双工光纤端口

返回页首

附录 B：测试配置文件

22 Kbps

图 33. 每种情况下的 22 Kbps 流的最大数目

图 34. 广播情况下的 22 Kbps 流

图 35.请求情况下的 22 Kbps 流

图 36.更改命名空间的请求情况下的 22 Kbps 流

缓冲命名空间更改：

<node name="PacketPump" opcode="create" >
<node name="MaxResendBufferSizeInMSecs" opcode="create" type="int32"
value="0x7d0" />
<node name="MaxBufferSizeInBytes" opcode="create" type="int32"
value="0x2000" />
<node name="OptimalBufferSizeInMSecsOnDemand" opcode="create"
type="int32" value="0x7d0" />
</node> <!-- PacketPump -->

56 Kbps

图 37. 每种情况下 56 Kbps 流的最大数目

图 38. 广播情况下的 56 Kbps 流

图 39. 请求情况下的 56 Kbps 流

图 40. 更改了命名空间的请求情况下的 56 Kbps 流

缓冲命名空间更改：

<node name="PacketPump" opcode="create" >
<node name="MaxResendBufferSizeInMSecs" opcode="create" type="int32"
value="0x1388" />
<node name="MaxBufferSizeInBytes" opcode="create" type="int32"
value="0x2000" />
<node name="OptimalBufferSizeInMSecsOnDemand" opcode="create"
type="int32" value="0x7d0" />
</node> <!-- PacketPump -->

100 Kbps

图 41. 每种情况下的 100 Kbps 流的最大数目

图 42. 广播情况下的 100 Kbps 流

图 43. 请求情况下的 100 Kbps 流

图 44. 更改了命名空间的请求情况下的 100 Kbps 流

缓冲命名空间更改：

<node name="PacketPump" opcode="create" >
<node name="MaxResendBufferSizeInMSecs" opcode="create"
type="int32"
value="0x1388" />
<node name="MaxBufferSizeInBytes" opcode="create" type="int32"
value="0x8000" />
<node name="OptimalBufferSizeInMSecsOnDemand" opcode="create"
type="int32" value="0xfa0" />
</node> <!-- PacketPump -->

300 Kbps

图 45. 每种情况下的 300 Kbps 流的最大数目

图 46. 广播情况下的 300 Kbps 流

图 47. 请求情况下的 300 Kbps 流

图 48. 更改命名空间的请求情况下的 300 Kbps 流

缓冲命名空间更改：

<node name="PacketPump" opcode="create" > <node name="MaxResendBufferSizeInMSecs" opcode="create" type="int32" value="0x2710" /> <node name="MaxBufferSizeInBytes" opcode="create" type="int32" value="0x10000" /> <node name="OptimalBufferSizeInMSecsOnDemand" opcode="create" type="int32" value="0x1f40" /></node> <!-- PacketPump -->

500 Kbps

图 49. 每种情况下 500 Kbps 流的最大数目图

图 50. 500kbps 广播

图 51. 请求情况下的 500 Kbps 流

1 Mbps

图 52. 每种情况下 1 Mbps 流的最大数目

图 53. 广播情况下的 1Mbps 流

图 54. 请求情况下的 1Mbps 流

无线 36 Kbps、64 Kbps、128 Kbps

广播无线情况

图 55. 启用了 FEC 和没有启用 FEC 的广播无线用户的最大数目

图 56. 启用了 FEC 和没有启用 FEC 的无线广播比较

请求无线情况

图 57. 启用了 FEC 和没有启用 FEC 的请求无线用户的最大数目

图 58. 启用了 FEC 和没有启用 FEC 的无线请求比较

没有启用 FEC 的缓冲命名空间设置：

32 Kbps

<node name="PacketPump" opcode="create" >
<node name="MaxResendBufferSizeInMSecs" opcode="create" type="int32"
value="0x7d0" />
<node name="MaxBufferSizeInBytes" opcode="create" type="int32"
value="0x2000" />
<node name="OptimalBufferSizeInMSecsOnDemand" opcode="create"
type="int32" value="0x7d0" />
</node> <!-- PacketPump -->

64 Kbps

<node name="PacketPump" opcode="create" >
<node name="MaxResendBufferSizeInMSecs" opcode="create" type="int32"
value="0x1388" />
<node name="MaxBufferSizeInBytes" opcode="create" type="int32"
value="0x2000" />
<node name="OptimalBufferSizeInMSecsOnDemand" opcode="create"
type="int32" value="0x7d0" />
</node> <!-- PacketPump -->

128 Kbps

<node name="PacketPump" opcode="create" >
<node name="MaxResendBufferSizeInMSecs" opcode="create"
type="int32" value="0x1388" />
<node name="MaxBufferSizeInBytes" opcode="create" type="int32"
value="0x8000" />
<node name="OptimalBufferSizeInMSecsOnDemand" opcode="create"
type="int32" value="0xfa0" />
</node> <!-- PacketPump -->

启用了 FEC 的缓冲命名空间设置：

32 Kbps

<node name="PacketPump" opcode="create" >
<node name="MaxResendBufferSizeInMSecs" opcode="create" type="int32"
value="0x0" />
<node name="MaxBufferSizeInBytes" opcode="create" type="int32"
value="0x2000" />
<node name="OptimalBufferSizeInMSecsOnDemand" opcode="create"
type="int32" value="0x7d0" />
</node> <!-- PacketPump -->

64 Kbps

<node name="PacketPump" opcode="create" >
<node name="MaxResendBufferSizeInMSecs" opcode="create" type="int32"
value="0x0" />
<node name="MaxBufferSizeInBytes" opcode="create" type="int32"
value="0x2000" />
<node name="OptimalBufferSizeInMSecsOnDemand" opcode="create"
type="int32" value="0x7d0" />
</node> <!-- PacketPump -->

128 Kbps

<node name="PacketPump" opcode="create" >
<node name="MaxResendBufferSizeInMSecs" opcode="create"
type="int32" value="0x0" />
<node name="MaxBufferSizeInBytes" opcode="create" type="int32"
value="0x8000" />
<node name="OptimalBufferSizeInMSecsOnDemand" opcode="create"
type="int32" value="0xfa0" />
</node> <!-- PacketPump -->

返回页首

附录 C：测试内容规范

下表显示了在 Windows Media Services 性能测试过程中，传送流式内容所使用的编码设置。显示的这些编码设置只供参考，不应该作为实现最大容量的基准值。

图 59. 内容编码设置

返回页首

附录 D：更改命名空间缓冲设置

警告：在编辑命名空间之前，请检查确认您有配置文件的备份副本，如果发生问题可以恢复。如果编辑命名空间不当，可能需要重新安装使用 Windows Media Services 命名空间设置的所有产品。Microsoft 无法保证因编辑命名空间不当而导致的问题可以解决。

停止 Windows Media Services（运行 net stop wmserver 命令）。

切换到命名空间文件所在的目录 (%SystemRoot%\System32\Windows Media\Server)。

在文本编辑器（例如记事本）中打开 ServerNamespace.xml 文件。

找到命名空间中的 Other 节点。

在 Other 节点之下、任何现有子节点之后添加 PacketPump 子节点：

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

将以下值添加到 PacketPump 子节点中，修改默认值。如果没有进行任何更改，则使用默认值。有关推荐的适当值，请参阅本文的“高级优化”部分。

<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" />

重新启动 Windows Media Services （运行 net start wmserver 命令）。

以下是一段示例代码，可以将它添加到 ServerNamespace.xml 文件中：

<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 -->

返回页首

附录 E：注册表项

警告：注册表编辑不当可能会对系统产生严重的损坏。在对注册表进行更改之前，应该先对计算机中有价值的数据进行备份。

FastSendDatagramThreshold
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AFD\Parameters\

FastSendDatagramThreshold。这个设置控制向客户端计算机发送数据报的方式。小于默认大小的数据报通过快速 I/O 路径传送或者在发送过程中进行缓冲。超过默认大小的数据报在实际发送之前先进行存储。快速 I/O 指的是服务器复制数据并跳过 I/O 子系统，而不是映射内存并通过 I/O 子系统。

给这个项设置的项值要比服务器传递的最高比特率流的包大小更大。

类型：DWORD

默认值：1024

推荐值：1500

返回页首

附录 F：性能计数器

在 Windows Media Services 测试中，以下性能计数器用于收集性能和可扩展信息。采样速率设置为 1 秒。

处理器：

\Processor(_Total)\% Processor Time
\Processor(_Total)\Interrupts/sec

Windows Media Services 计数器：

\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(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\Context Switches/sec

系统内存计数器：

\Memory\Page Faults/sec
\Memory\Cache Bytes
\Memory\Committed Bytes
\Memory\Available Bytes

物理磁盘计数器：

\PhysicalDisk(_Total)\% Disk Time
\PhysicalDisk(_Total)\Current Disk Queue Length
\PhysicalDisk(_Total)\Disk Bytes/sec
\PhysicalDisk(_Total)\Disk Read Bytes/sec

网络接口计数器：

\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

远程文件系统 — NTB 连接（TCP/IP 上的 NetBIOS）：

\NBT Connection(Total)\Bytes Received/sec
\NBT Connection(Total)\Bytes Sent/sec
\NBT Connection(Total)\Bytes Total/sec

返回页首

更多信息

要了解有关 Windows Media Services 9 Series 的更多信息，请参阅 Windows Media Services 帮助。

相关文章：

•	Upgrading to Windows Media Services 9 Series

转载于:https://www.cnblogs.com/hmmcsdd/archive/2007/10/12/youhuawms9.html