【IT168 专稿】WWW负载生成器可以用来评估web服务器性能，因此对服务器性能优化有很重要的指导作用。但是当前的评估如WebStone、SPECWeb大多是在局域网环境下进行，忽略了一个重要方面：实际应用中，这些服务器在广域Internet上的表现如何呢？

    为了分析WAN条件是如何影响WWW服务器性能（WASP，Wide-Area Server Performance）的，笔者通过模拟WAN的特征，引入一些因素，比如，在可控和可再生条件下的延迟和包丢弃，通过实验来检测WAN对服务器的影响。我们研究这些因素如何与主机TCP的实现相互作用，以及这些因素对服务器性能的影响。

    关于WWW服务器，主要有三点需要关注：观察到的吞吐量、客户端得到数据的响应时间以及最大吞吐量（容量）。如果忽略WAN条件，服务器可以很容易的发挥最大功效，然而一旦处于WAN中，延迟和丢弃会使服务器达到其最大容量变得十分困难。观察到的吞吐量会使我们对服务器的性能产生误判。

    分析表明，当服务器处于真实的广域网条件下，其性能表现与现行的在局域网下测评的表现有着天壤之别，表现出截然不同的性能属性和等级行为。

一、WASP测试环境

1）硬件和操作系统软件

     我们的测试环境有8台作客户端的PC，一个千兆交换机和一个基于RISC的服务器。客户端配置：处理器：500MHz Pentium Ⅲ ；内存： 96MB；操作系统：FreeBSD 3.3 ；每台客户端都带有100M网卡接口，然后用交换机将它们点对点全双工联接起来。服务器采用为IBM RS/6000 43P 260：200MHz Power 3处理器，具有4MB L2缓存和256内存，运行IBM的UNIX操作系统AIX 4.3.3，用千兆网卡与交换机相连。

    在服务器操作系统中，我们用SACK 和New Reno协议来扩充TCP/IP协议栈。AIX的TCP/IP协议栈是从BSD 4.4发展过来。AIX系统本身就是先前为了处理大规模工作量而设计的。

    在客户端操作系统，我们结合FreeBSD 2.6到3.3的Rizzo SACK源代码，共同实现服务器SACK的实现。

2）WWW服务器软件

     当前许多web服务器采用了不同的架构和最优化设计，所以就有不同的性能特征。如果只关注于一个特定的实现过程，那我们的研究就会有局限性。为了把这种局限降到最低，我们将会同时检测WAN对通用型和优化型服务器的影响。我们决定采用两种服务器：Apache, 作为通用服务器的代表；Flash，则作为优化型的例子。

3）WWW客户负载生成器软件

    我们用两个HTTP负载生成器去评估WWW服务器性能。S-client作为微型测试，生成对服务器上同一文件的大量请求，能使我们观察到性能如何随请求文件大小而变化。我们自用另一种负载生成器Waspclient用于大型测试，评估更实际的累计行为。

    S-client是轻量级、基于事件请求的生成器，它使用单一的进程和select()系统命令去管理大量面向服务器的并发动态连接。在我们的测试环境中，每个客户端机器运行单一的s-client进程，此进程一次能生成2048个并发连接。图1显示的是负载生成的结构图。

图1. 负载生成的结构图

     整个系统是一个封闭式队列网络，这就意味着我们可以调整客户端数目。通过改变并发连接数，我们能改变测试时负载。这就可以观察当负载增加时系统表现出来的性能，以及改变参数（像分组往返时间Round Trip Time，丢帧率Loss Rate）来看系统行为的变化。

     Waspclient是从s-client和SURGE测试软件的源代码改进而来。SURGE作为负载生成器用于捕捉WWW站点的各种通信特征，包括重尾文件分布(Heavy-tailed File Distribution)和请求大小分布（Request Size Distribution）。SURGE不能产生足够大的负载使服务器达到饱和。但是，SURGE提供了更为贴近实际的负载情况，所以我们这里采用它。

二、WASP 环境架构设计

    WASP环境的设计是模拟WAN特征，比如包丢弃或延迟。它的目的是想要生成一个更贴近实际的通信量，通过这样检测服务器，对于它的容量设计就很有帮助。我们系统的一个重要特征就是孤立性和可再生性，然而实际中的Internet总是处于不断变化中。但为了便于研究和诊断性能方面的问题，我们的系统要求实验可重复。

    由于互联网的多元化，任何一个特定的站点都不可能具有完全的代表性，所以我们希望观察大多数服务器通用的一系列参数，而不是仅仅限于一个点。我们做了一些服务器对条件的灵敏度分析，比如我们改变参数包延迟，从0一直到400ms，然后我们试图找到延迟对于服务器吞吐量的影响。另外，我们系统的优点在于可配置性：

1．站点主机操作人员能更根据网站自身配置系统参数，如果今后需要还可以随时改变它们；
2．可以在相同的条件下，重复地分析和实验。

     缺点在于模拟的条件可能与实际没有那么相符，但我们还是相信实验结果要比非WAN条件下的要真实许多，这些提炼出来的结果能使我们对现实的因特网有更好的理解。

    先前引入包丢弃和延迟的方法是在底层结构中，添加一个单一独立的机器，它的功能是作为一个WAN模拟器。如图2所示。有时这个机器又被称为延迟路由器。WAN的功能集中于一个单一的机器，我们称之为集中式方法。这个方法优点在于不需要对客户端和服务器的软件进行调整，这对非开源的系统是需要的。这个方法主要用于协议正确性的测试，而如果是在客户端产生的高负载的情况下，它是无法对WWW服务器性能做出评估的。

图2. 集中式方法

     于是我们用如图3所示的结构来代替，在这个结构中，我们用到了了FreeBSD中的虚拟网层(Dummynet layer)，包延迟和包丢弃就可以直接引入客户端，如图4所示。虚拟网层处在协议栈的下方，所以对应用层是透明的。虚拟网层对于穿越协议栈的包应用包过滤规则，根据规则来决定是否丢弃或延迟。

图3. WASP 方法

图4. 虚拟网架构

     为了延迟包的发送，虚拟网层用FreeBSD中的time-out()工具，默认的发送事件间隔是10ms。如果配置虚拟网层不起延迟作用，包就绕过time-out()工具，直接传送。对于包丢弃，虚拟网层使用一个随机丢弃模型，它能设定一个丢包概率。虚拟网层中的丢弃模型相对独立，不会因为过去的丢包决定而影响当前在线包的处理。同样，这对于测试协议正确性是有用的，但在很大程度上并不是实际因特网上包丢弃行为的真实描述。

    我们把虚拟网（Dummynet）进一步扩展并和丢弃模型相结合，如图5所示，模型中有两个相对独立的状态。

图5. 两种状态的丢弃模型

    每个穿越虚拟网的连接都处于这两个状态：要么是“好”的状态，要么是“坏”的状态。对于处在“好”的状态的连接，虚拟网传送所有的数据包；对于处于“坏”的状态的，所有包被丢弃。从好的状态转到坏的状态的转化率取决与丢弃事件概率（loss event probability），这个与全部包丢弃率不同。保持在“坏”的状态的可能性就是条件性丢弃概率（conditional loss probability），也就是，当前一个包丢弃，后一个包丢弃的概率。从坏的状态到好的状态的过渡是丢弃事件概率（loss event probability）的反转。这些控制着每个丢弃事件的持续时间和丢弃包的数量。这个虚拟网的扩展维持着每个连接的状态，通过一个连接观察到的包丢弃相互关联的，但不同连接的丢弃是独立的。

三、实验方法

     我们实验环境一个重要的考虑事项就是要能根据需要，科学的可重复性，同时还要兼顾检查尽可能多的配置方法。因此我们采用下列方法。实验中，用s-client测量对三种代表性文件大小的请求：1KB代表的小文件，8KB代表中等文件，64KB代表大文件。数据点都会是这三个文件取值的平均数。每60秒取样一次，在30秒的预热后，客户端对文件的请求达到稳定。对于64K的文件，因为文件大，传送时间长，所以取样间隔时间设在5分钟。对于使用Waspclient的测试，30秒预热后，取样间隔时间一律设在10分钟，同样取三个文件值的平均数。

四、结  论

     限于文章篇幅，我们无法一一给出包丢弃和延迟如何影响服务器的吞吐量、响应时间和服务器容量的具体数据。仅仅给出最后结论：

• 分组往返时间（RTT）与包丢弃有关系。引入包延迟和丢弃对服务器吞吐量有实质的影响。一旦引入丢弃和延迟，服务器就很难再全速运转。不同的服务器对条件的反应不同，所以在测试中引入这些特性很重要。
• 包丢弃减少了吞吐量，增加了潜伏期。上升的丢弃率减少了服务器容量，减少量能达到50％之多，并且增加了响应时间。
• 包延迟增加了潜伏期，但没有减少吞吐量。RTT数值很大时，服务器对客户端的响应就慢，但总的服务器容量并没有受到影响。
•  Reno, SACK和New Reno 的表现是不同的。不同版本的TCP对包丢弃的反应有很大的不同。使用SACK或New Reno不会改变服务器吞吐量，但是能降低响应时间。我们得出结论：服务器必须配置这些TCP变量。