技术文栏 - 优化 Microsoft Windows Media 服务器（二）电影音乐图片 flash IIS Windows Media Real Helix 防盗链防下载软件

游客，您好

免费注册

用户中心

支持中心

加入收藏

技术文栏 - 流媒体相关 - Windows Media - 浏览文章

优化 Microsoft Windows Media 服务器（二）

发布日期：2007-2-18 8:36:03 作者：出处：

添加到百度搜藏

性能评估

本节讨论基于以下因素的性能评估：协议、速率、广播发布点与按需传输数据流、处理器数目、单速率与多速率，以及 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

更改键值的副作用是增加了为服务器分配的不分页缓冲池的字节数。不过，如上图所示，这种增加并不会引起任何问题。下面的图表显示了当数据包大小超过键值时上下文切换的增加情况。

共有1条文章页次：1/1

分页：

9 1 :


发布人：-----	【大中小】·【推荐好友】·【打印】·【顶部】

[Windows Media] ·Windows Media技术平台概览	2007-02-18
[Windows Media] ·Windows Media 组件	2007-02-18
[Windows Media] ·Windows Media 术语表	2007-02-18
[Windows Media] ·Windows Media Services 4.1	2007-02-18
[Windows Media] ·Windows Media Encoder	2007-02-18