中国视频在线(www.chinavideoonline.com)致力于收集各种流媒体相关的技术资料，以及流媒体常识和应用方案，力求为广大朋友了解学习和使用流媒体技术提供帮助
优化 Microsoft Windows Media 服务器（二）
作者/来源：www.chinabctv.com
性能评估
本节讨论基于以下因素的性能评估：协议、速率、广播发布点与按需传输数据流、处理器数目、单速率与多速率，以及 FastSendDatagramThreshold 键值。
协议
下面的图表显示，在按需传输数据流时，CPU 的使用并不随之呈线性增加。根据性能测试的结果，在连接 4000 个 MMSU 客户端时，CPU 的使用率为 27%。而再增加 500 个客户端，便会使 CPU 的负载上升到 60%。下面的图表显示了针对 MMSU、MMST 和 HTTP 协议的 CPU 使用情况。
在相同的 CPU 负载水平上，与 MMST 或 HTTP 协议（2700 个客户端）相比，MMSU 协议可以多传输 53% 的客户端（4000 个）。
图 1
下面的图表显示了测试结果。
图 2
对于 22 Kbps 的测试文件，每个客户端使用的内存量如下：MMSU 为 103 KB，HTTP 为 63.5 KB，而 MMST 为 62.9 KB。虽然 MMSU 协议对 CPU 的使用比较少，但它需要更多的内存（比 MMST 多 60%）。
速率
当评估 Windows Media 服务器可以支持的客户端数目时，应了解服务器针对不同速率的变化情况。这里分别以传输 22 Kbps 和 220 Kbps 文件对服务器进行了测试。使用 22 Kbps 文件时，一次连接 500 个客户端，而使用 220 Kbps 文件时，一次连接 50 个客户端。总吞吐量是相等的，但客户端的数目和文件的速率不同。
下面的图表显示，500 个 22 Kbps 的数据流比 50 个 220 Kbps 的数据流使用更多的 CPU。因此，CPU 的使用并不随速率线性增加，而是呈阶段性增长。
图 3
其直接结果是不能在一个千兆 NIC 上传输 22 Kbps 文件并使之饱和，因为这样很多系统的处理能力会被耗尽。而在传输 700 Kbps 或 1 Mbps 文件时，CPU 很可能并不成为限制因素。在高速流文件测试中，CPU 的问题远远少于 NIC 和磁盘速度问题。
图 4
内存的使用情况也是这样。在传输 22 Kbps 数据流时，每 Kbps 的输出将占用 730 字节的 RAM，但对于 220 Kbps 的数据流，却降至只有 90 字节。
对于 CPU 和内存，数据流的速率越高，服务器性能越好。
广播发布点与按需传输数据流
从广播发布点 (BPP) 传输数据（由实时输入或工作站提供）比按需传输数据流使用更少的资源。两种传输类型最大的区别在于，BPP 传输基本呈线性变化，而按需传输则近似于指数关系。下面的图表显示了实时和按需传输的处理时间。
图 5
当 CPU 的使用率低于 35% 时，按需传输使用的处理器时间比 BPP 少。但是，如果使用 BPP，系统管理员不仅可以更容易地预测系统所能支持的客户端数目，而且能够连接更多的客户端。在本文档发布时，单个 Windows Media 服务器最多可以连接 9,500 个 22 Kbps 客户端。客户端从多个 BPP 流出。
图 6
BPP 数据流使用的内存也相对较少。对于每个 22 Kbps MMSU 客户端，服务器使用 16.3 KB 的内存。而对于按需传输的数据流，服务器使用约 103 KB 的内存。如果要将 22 Kbps 文件流向 4,000 个提出请求的单路传输客户端，则服务器需要安装大约 512 MB 的 RAM。使用实时数据流时，流入到相同数目的客户端只需要安装 128 MB 的 RAM。
处理器数目
当增加处理器时，根据主要是实时传输还是按需传输，Windows Media 服务器的变化会有很大差异。
图 7
对于按需传输，处理器的数目和系统支持的客户端的数目并不以相同的比例增加。使用一个处理器时，最多可以连接 2,000 个客户端，而且 CPU 的使用率最高为 30%。使用两个处理器时，可以连接 2,600 个客户端（平均每个处理器连接 1,300 个）。使用四个处理器时，可以连接 4,200 个客户端（平均每个处理器连接 1,050 个）。
另一方面，对于实时文件，服务器的性能则按比例变化，如下图所示。
图 8
同样保持 30% 左右的 CPU 使用率，使用一个处理器可以连接约 1,000 个客户端，使用两个处理器可以连接约 2,000 个客户端，而使用四个处理器可以连接约 4,000 个客户端。
单速率与多速率
多速率 (MBR) 文件的问题在于，必须从磁盘读取所有不同的速率，而不管客户端当前所接收的速率如何。由于从磁盘读取的数据量较大，会出现读取滞后的情况。
除此之外，MBR 文件的行为与单速率 (SBR) 文件基本类似。对于按需传输，内存的使用率会按比例增加，而 CPU 的使用却不是这样。
FastSendDatagramThreshold 键值
性能测试显示，设置更适当的 FastSendDatagramThreshold 键值会显著提高服务器的性能。在 Microsoft Windows® 2000 中，此键值可用于确定数据文报是通过快速 I/O 通道传输，还是在发送时被缓冲。快速 I/O 意味着将复制数据并通过 I/O 子系统进行传输，而并不映射内存和通过 I/O 子系统。
注意： 本段摘自 Dave MacDonald 撰写的“Microsoft Windows 2000 TCP/IP Implementation Details:
TCP/IP Protocol Stack and Services”。
FastSendDatagramThreshold 键值的默认值为 1,024。如果传输的数据包超过此值，则需要进行其他操作。结果将增加上下文切换量和 CPU 的使用率，而服务器可以连接的最大客户端数目则会减少。下面的图表显示了系统将键值更改为更优化的值（本例中为 1,500 字节）前后的结果。
图 9
更改键值后，只对高速文件有好处，因为只有这些文件是以超出默认限值的数据包发送的。通常 100 Kbps 的速率会首先使带有 .asf 扩展名的各个 Windows 媒体文件被分为大于 1,024 字节的数据包。要确定适当的键值，必须首先确定 Windows 媒体文件数据包的大小，然后将该键值设置为更大的数值。
注意： 下面是某些典型的值：对于 100 Kbps 的数据流，将该键值设置为 4,096，对于 500 Kbps 的数据流，将该键值设置为 9,600，对于 1 Mbps 的数据流，将该键值设置为 1,6000。
如果不更改键值，在 CPU 的使用率保持在 30% 以下时，服务器可连接 750 个客户端。更改键值后，则可以连接 1,050 个客户端，增加了 40%。
图 10
更改键值的副作用是增加了为服务器分配的不分页缓冲池的字节数。不过，如上图所示，这种增加并不会引起任何问题。下面的图表显示了当数据包大小超过键值时上下文切换的增加情况。
本节讨论基于以下因素的性能评估：协议、速率、广播发布点与按需传输数据流、处理器数目、单速率与多速率，以及 FastSendDatagramThreshold 键值。
协议
下面的图表显示，在按需传输数据流时，CPU 的使用并不随之呈线性增加。根据性能测试的结果，在连接 4000 个 MMSU 客户端时，CPU 的使用率为 27%。而再增加 500 个客户端，便会使 CPU 的负载上升到 60%。下面的图表显示了针对 MMSU、MMST 和 HTTP 协议的 CPU 使用情况。
在相同的 CPU 负载水平上，与 MMST 或 HTTP 协议（2700 个客户端）相比，MMSU 协议可以多传输 53% 的客户端（4000 个）。
图 1
下面的图表显示了测试结果。
图 2
对于 22 Kbps 的测试文件，每个客户端使用的内存量如下：MMSU 为 103 KB，HTTP 为 63.5 KB，而 MMST 为 62.9 KB。虽然 MMSU 协议对 CPU 的使用比较少，但它需要更多的内存（比 MMST 多 60%）。
速率
当评估 Windows Media 服务器可以支持的客户端数目时，应了解服务器针对不同速率的变化情况。这里分别以传输 22 Kbps 和 220 Kbps 文件对服务器进行了测试。使用 22 Kbps 文件时，一次连接 500 个客户端，而使用 220 Kbps 文件时，一次连接 50 个客户端。总吞吐量是相等的，但客户端的数目和文件的速率不同。
下面的图表显示，500 个 22 Kbps 的数据流比 50 个 220 Kbps 的数据流使用更多的 CPU。因此，CPU 的使用并不随速率线性增加，而是呈阶段性增长。
图 3
其直接结果是不能在一个千兆 NIC 上传输 22 Kbps 文件并使之饱和，因为这样很多系统的处理能力会被耗尽。而在传输 700 Kbps 或 1 Mbps 文件时，CPU 很可能并不成为限制因素。在高速流文件测试中，CPU 的问题远远少于 NIC 和磁盘速度问题。
图 4
内存的使用情况也是这样。在传输 22 Kbps 数据流时，每 Kbps 的输出将占用 730 字节的 RAM，但对于 220 Kbps 的数据流，却降至只有 90 字节。
对于 CPU 和内存，数据流的速率越高，服务器性能越好。
广播发布点与按需传输数据流
从广播发布点 (BPP) 传输数据（由实时输入或工作站提供）比按需传输数据流使用更少的资源。两种传输类型最大的区别在于，BPP 传输基本呈线性变化，而按需传输则近似于指数关系。下面的图表显示了实时和按需传输的处理时间。
图 5
当 CPU 的使用率低于 35% 时，按需传输使用的处理器时间比 BPP 少。但是，如果使用 BPP，系统管理员不仅可以更容易地预测系统所能支持的客户端数目，而且能够连接更多的客户端。在本文档发布时，单个 Windows Media 服务器最多可以连接 9,500 个 22 Kbps 客户端。客户端从多个 BPP 流出。
图 6
BPP 数据流使用的内存也相对较少。对于每个 22 Kbps MMSU 客户端，服务器使用 16.3 KB 的内存。而对于按需传输的数据流，服务器使用约 103 KB 的内存。如果要将 22 Kbps 文件流向 4,000 个提出请求的单路传输客户端，则服务器需要安装大约 512 MB 的 RAM。使用实时数据流时，流入到相同数目的客户端只需要安装 128 MB 的 RAM。
处理器数目
当增加处理器时，根据主要是实时传输还是按需传输，Windows Media 服务器的变化会有很大差异。
图 7
对于按需传输，处理器的数目和系统支持的客户端的数目并不以相同的比例增加。使用一个处理器时，最多可以连接 2,000 个客户端，而且 CPU 的使用率最高为 30%。使用两个处理器时，可以连接 2,600 个客户端（平均每个处理器连接 1,300 个）。使用四个处理器时，可以连接 4,200 个客户端（平均每个处理器连接 1,050 个）。
另一方面，对于实时文件，服务器的性能则按比例变化，如下图所示。
图 8
同样保持 30% 左右的 CPU 使用率，使用一个处理器可以连接约 1,000 个客户端，使用两个处理器可以连接约 2,000 个客户端，而使用四个处理器可以连接约 4,000 个客户端。
单速率与多速率
多速率 (MBR) 文件的问题在于，必须从磁盘读取所有不同的速率，而不管客户端当前所接收的速率如何。由于从磁盘读取的数据量较大，会出现读取滞后的情况。
除此之外，MBR 文件的行为与单速率 (SBR) 文件基本类似。对于按需传输，内存的使用率会按比例增加，而 CPU 的使用却不是这样。
FastSendDatagramThreshold 键值
性能测试显示，设置更适当的 FastSendDatagramThreshold 键值会显著提高服务器的性能。在 Microsoft Windows® 2000 中，此键值可用于确定数据文报是通过快速 I/O 通道传输，还是在发送时被缓冲。快速 I/O 意味着将复制数据并通过 I/O 子系统进行传输，而并不映射内存和通过 I/O 子系统。
注意： 本段摘自 Dave MacDonald 撰写的“Microsoft Windows 2000 TCP/IP Implementation Details:
TCP/IP Protocol Stack and Services”。
FastSendDatagramThreshold 键值的默认值为 1,024。如果传输的数据包超过此值，则需要进行其他操作。结果将增加上下文切换量和 CPU 的使用率，而服务器可以连接的最大客户端数目则会减少。下面的图表显示了系统将键值更改为更优化的值（本例中为 1,500 字节）前后的结果。
图 9
更改键值后，只对高速文件有好处，因为只有这些文件是以超出默认限值的数据包发送的。通常 100 Kbps 的速率会首先使带有 .asf 扩展名的各个 Windows 媒体文件被分为大于 1,024 字节的数据包。要确定适当的键值，必须首先确定 Windows 媒体文件数据包的大小，然后将该键值设置为更大的数值。
注意： 下面是某些典型的值：对于 100 Kbps 的数据流，将该键值设置为 4,096，对于 500 Kbps 的数据流，将该键值设置为 9,600，对于 1 Mbps 的数据流，将该键值设置为 1,6000。
如果不更改键值，在 CPU 的使用率保持在 30% 以下时，服务器可连接 750 个客户端。更改键值后，则可以连接 1,050 个客户端，增加了 40%。
图 10
更改键值的副作用是增加了为服务器分配的不分页缓冲池的字节数。不过，如上图所示，这种增加并不会引起任何问题。下面的图表显示了当数据包大小超过键值时上下文切换的增加情况。
(C) 2004-2006 中国视频在线 技术支持：梦想家网络工作室