使用WAS对Web应用程序进行压力测试

msnshow

WAS（Microsoft Web Application Stress Tool，Web应用负载测试工具）提供了一种简单的方法模拟大量用户来访问你的网站。这个工具能告诉我们你的Web应用程序工作时对硬件和软件的使用情况。在本文中我将告诉大家如何使用WAS，以及如何理解WAS测试的数据。

msnshow

1 压力测试的必要性
        随着服务器端处理任务的日益复杂以及网站访问量的迅速增长，服务器性能的优化也成了非常迫切的任务。在优化之前，最好能够测试一下不同条件下服务器的性能表现。找出性能瓶颈所在是设计性能改善方案之前的一个至关紧要的步骤。
        负载测试是任何Web应用的开发周期中一个重要的步骤。如果你在构造一个为大量用户服务的应用，搞清楚你的产品配置能够承受多大的负载非常重要。如果你在构造一个小型的Intranet网站，测试能够暴露出最终会导致服务器崩溃的内存漏洞以及竞争情况。
        但是在实际的开发过程中，要按照实际投入运行的情况，组织成千上万的用户来进行压力测试，无论从那个方面看，都是不现实的。而且这样一旦发现了问题，不仅需要重复的进行这种耗费巨大的测试，而且问题不容易重现，不能方便的找出性能的瓶颈所在。而使用软件进行压力测试就不会存在这种情况。
        无论是哪种情形，花些时间对应用进行负载测试可以获得重要的基准性能数据，为未来的代码优化、硬件配置以及系统软件升级带来方便。即使经费有限的开发组织也可以对它们的网站进行负载测试，因为Microsoft的压力测试工具WAS是可以免费下载的。

msnshow

2 WAS概要介绍

为了有效的对Web应用程序进行压力测试，Microsoft发布了这个简单易用，功能强大的工具WAS。WAS要求Windows NT
4.0 SP4或者更高，或者Windows
2000。为了对网站进行负载测试，WAS可以通过一台或者多台客户机模拟大量用户的活动。WAS支持身份验证、加密和Cookies，也能够模拟各种浏览器类型和Modem速度，它的功能和性能可以与数万美元的产品相媲美。

使用WAS时，为了更加接近真实的进行压力测试，我们推荐运行WAS的测试机和Web Server分开。

msnshow

3 开始使用WAS

要对网站进行负载测试首先必须创建WAS脚本模拟用户活动。我们可以用下面四种方法之一创建脚本：

l 通过记录浏览器的活动

l 通过导入IIS日志

l 通过把WAS指向Web网站的内容

l 手工制作

在这里我们拿最常用的方法——通过记录浏览器的活动 来讲解。其他三种方法在后面将会提到。

3.1 录制测试脚本

打开菜单，选择Scripts|Create|Record 创建一个测试脚本

msnshow

选取要记录的内容，有下面3种

msnshow

l Record delay between request：记录了请求之间的延迟。由于用户实际上在浏览网站时，请求之间存在几秒甚至几分钟的延迟，这种录制方法在执行时会模仿用户之间的延迟发送请求，所以会是一个更加实际的测试。如果我们的目的是要发现Web应用程序的承受极限，就不要选择该项；如果只是想模拟一个特定数量的用户场景，那么选择该项进行测试捕捉请求延迟。

l Record browser cookies & Record the host header：只记录用户的会话，不记录延迟时间。一般情况下，我们不需要选择这两项，可以让WAS创建cookies和host header，就好像用户登陆你的网站一样。然而，如果你有网站的回归信息时（比如一个用户的主要特征信息或者与一个永久性cookies相连的其他信息），在模拟一个新的用户登陆网站和进行必要的用户配置测试前，必须保证清除 cookies，如果Web应用程序需要用户接受cookies，那么需要选中该选项。

目前这个版本的WAS软件对基于浏览器IE录制脚本的方式还不支持HTTP/SSL请求。一般情况下，只选择后二种会增加压力的强度。

根据压力测试实际的情况，选择合适的选项，然后点“Next | Finish”，WAS会打开一个IE窗口，在IE中输入要测试的站点地址，然后我们就可以按照实际的情况开始浏览站点了，浏览的同时也就是执行测试用例的过程。

msnshow

等测试用例执行完成后，切换到WAS窗口，点“Stop Recording:”按钮，停止录制脚本

msnshow

WAS回到了视图页面，在该页面中你可以看到在录制过程中WAS收集的每一个链接，而且还可以编辑GET、POST以及HEAD信息。

msnshow

制作WAS脚本是相当简单的，不过要制作出模拟真实用户活动的脚本有点儿复杂。如果你已经有一个运行的Web网站，可以使用Web服务器的日志来确定Web网站上的用户点击分布。如果你的应用还没有开始运行，那么只好根据经验作一些猜测了。

3.2 负载参数设置

测试脚本录制完成后，下一步我们要作的就是配置运行脚本的负载选项，我们可以调整测试配置以便观察不同条件下的应用性能。

3.2.1 Content Tree

由于我们的WAS和Web Server是分开的，所以这里我们不需要设置

3.2.2 Setting（设置）

我们只要点击“Setting”就开始负载选项设置。

msnshow

1. ConCurrent
Connections：
Stress Level（threads）的数值决定了所有客户机创建的Windows的线程的数值。每一个线程创建多个Socket连接（具体多少Socket连接数取决于Stress multiplier (sockets per thread)），每个Socket连接就是一个并发的请求(request)。下面这个公式表示了它们之间的关系：
         总的并发请求数 = Stress Level * Stress multiplier = 总的Socket连接数


Stress Level和Stress
multiplier这二个项决定了访问服务器的并发连接的数量。Microsoft建议不要选择超过100的Stress
Level值。如果要模拟的并发连接数量超过100个，可以调整Stress
multiplier或使用多个客户机。在负载测试期间WAS将通过DCOM与其他客户机协调。

2. Test Run Time：设定持续运行多长时间的测试。我们可以在这里设定让WAS持续运行多少天、多少个小时、多少分钟、多少秒

3. Request Delay（in milliseconds）：设定请求延迟时间的最大、最小值，当然我们也可以选择“Use random delay”使用随机的延迟时间。一般情况下，我们常常会浏览一页，发现一个链接后，我们点击它。即便对该网站熟悉的人，

4. Suspend： WAS允许设置warmup（热身）时间，一般可以设置为1分钟。在warmup期间WAS开始执行脚本，但不收集统计数据。warmup时间给MTS、数据库以及磁盘缓冲等一个机会来做准备工作。如果在warmup时间内收集统计数据，这些操作的开销将影响性能测试结果。WAS也允许设置CoolDown时间。在WAS执行的时间达到设定的Test Run Time时，进入CoolDown Time，这时WAS并没有停止执行脚本，同样也不会收集统计数据。下图表示了它们的先后关系。

file:///e:/Temp/ksohtml/wps_clip_image-10240.pngWarmUp 不收集统计数据

file:///e:/Temp/ksohtml/wps_clip_image-4198.pngTest Run Time 收集统计数据

CoolDown 不收集统计数据

5. Bandwith：设置页面提供的另外一个有用的功能是限制带宽（throttle bandwidth）。带宽限制功能能够为测试模拟出Modem（14.k K，28.8
K，56 K）、ISDN（64 K，128 K）以及T1（1.54
M）的速度。使用带宽限制功能可以精确地预测出客户通过拨号网络或其他外部连接访问Web服务器所感受的性能。

6. Redirects、Throughput、Name resolution：
这几个选项一般情况下采用默认情况即可。
选中Follow HTTP redirects选项将会支持重定向。
选中Throughput中的两项，WAS将会收集活动用户的cookies，以及收集网站的统计数字。默认情况下都会选中这两项，如果不选择，将会增加压力测试的强度。
Name resolution默认情况下没有选中。选中该选项，会让每一个客户测试机执行查询，只有在使用多个子网时才需要选中该项。（帮助原文：have each individual test client perform a lookup，this is useful when using multiple subnets）

msnshow

3.2.3 Perf Counters（性能计数器）

使用WAS，从远程Windows NT和Windows 2000机器获取和分析性能计数器（Performance
Counter）是很方便的。加入计数器要用到下图所示的Perf Counters分枝。

msnshow

一般情况下，这里需要添加的性能计数器有：

1  Web Server：

·
处理器：CPU使用百分比（% CPU Utilization）

·
内存：内存使用百分比（% Memory Utilization）

·
线程：每秒的上下文切换次数（Context Switches Per Second (Total)）

·
ASP：每秒请求数量（Requests Per Second）

·
ASP：请求执行时间（Request Execution Time）

·
ASP：请求等待时间（Request Wait Time）

·
ASP：置入队列的请求数量（Requests Queued）

   2   各个WAS测试机

·
处理器：CPU使用百分比（% CPU Utilization）

·
内存：内存使用百分比（% Memory Utilization）

在测试中选择哪些计数器显然跟测试目的有关。虽然下面这个清单不可能精确地隔离出性能瓶颈所在，但对一般的Web服务器性能测试来说却是一个好的开始。

· 处理器：CPU使用百分比（% CPU Utilization）

· 线程：每秒的上下文切换次数（Context Switches Per Second (Total)）

· ASP：每秒请求数量（Requests Per Second）

· ASP：请求执行时间（Request Execution Time）

· ASP：请求等待时间（Request Wait Time）

· ASP：置入队列的请求数量（Requests Queued）

　　CPU使用百分比反映了处理器开销。CPU使用百分比持续地超过75%是性能瓶颈在于处理器的一个明显的迹象。每秒上下文切换次数指示了处理器的工作效率。如果处理器陷于每秒数千次的上下文切换，说明它忙于切换线程而不是处理ASP脚本。

　　每秒的ASP请求数量、执行时间以及等待时间在各种测试情形下都是非常重要的监测项目。每秒的请求数量告诉我们每秒内服务器成功处理的ASP请求数量。执行时间和等待时间之和显示了反应时间，这是服务器用处理好的页面作应答所需要的时间。

我们可以绘出随着测试中并发用户数量的增加每秒请求数量和反应时间的变化图。增加并发用户数量时每秒请求数量也会增加。然而，我们最终会达到这样一个点，此时并发用户数量开始“压倒”服务器。如果继续增加并发用户数量，每秒请求数量开始下降，而反应时间则会增加。要搞清楚硬件和软件的能力，找出这个并发用户数量开始“压倒”服务器的临界点非常重要。

　　置入队列的ASP请求数量也是一个重要的指标。如果在测试中这个数量有波动，某个COM对象所接收到的请求数量超过了它的处理能力。这可能是因为在应用的中间层使用了一个低效率的组件，或者在ASP会话对象中存储了一个单线程的单元组件。

运行WAS的客户机CPU使用率也有必要监视。如果这些机器上的CPU使用率持续地超过75%，说明客户机没有足够的资源来正确地运行测试，此时应该认为测试结果不可信。在这种情况下，测试客户机的数量必须增加，或者减小测试的Stress
Level。

3.2.4 Page Groups

对于一个Web应用而言，同一时刻用户点击分布是不一样的。WAS允许设置用户点击流量的分布比例。

msnshow

这里我们假设在一个Web应用程序中，有650个人同时在线，其中100人正在添加提交数据，占15.38%；有150人正在查询，占23.08%。

按照不同的Web应用，我们可以根据实际的情况在定制这个比例关系，来更加符合实际的情况。

3.2.5 Users

现在很多Web应用程序为了提供个性化的服务，都设计了登陆过程。每个用户都有自己的登陆名和密码。WAS也考虑到了这种情况，我们只要在Users分支中添加用户名和对应的密码即可。

msnshow

3.2.6 Clients

添加多个WAS客户机。在运行期间，各个WAS客户机是通过DCOM来协调的。各个WAS客户机只要正确安装了WAS软件，启动了WebTool服务，它们就可以自己协调操作。

我们只要在Clients分支内添加WAS客户机即可。

msnshow

3.2.7 Cookies

这里显示的是用户名以及对应的cookies。这里不需要设置。

4 运行测试脚本

所有的设置完成以后，我们就可以运行WAS来进行压力测试了。要运行测试脚本很简单，只要选中测试脚本的名称，然后点工具栏上的“运行”按钮，即可。

建议：第一次运行测试脚本时，Test Run Time不要太长，Stress Level以及Stress multiplier不要太大。第一次运行的目的只是为了检验测试脚本正确的运行。

msnshow

5 测试结果

每次测试运行结束后WAS会生成详细的报表，即使测试被提前停止也一样。WAS报表可以从View菜单选择Reports查看。下面介绍一下报表中几个重要的部分。

5.1 摘要

页面摘要部分提供了页面的名字，接收到第一个字节的平均时间（TTFB），接收到最后一个字节的平均时间（TTLB），以及测试脚本中各个页面的命中次数。TTFB和TTLB这两个值对于计算客户端所看到的服务器性能具有重要意义。TTFB反映了从发出页面请求到接收到应答数据第一个字节的时间总和（以毫秒计），TTLB包含了TTFB，它是客户机接收到页面最后一个字节所需要的累计时间。

只要选中页面的名字，即可显示页面概要。

msnshow

5.2 Result Codes

如果这是一个新创建的测试脚本，你应该检查一下报表的Result
Codes部分。这部分内容包含了请求结果代码、说明以及服务器返回的结果代码的数量。如果这里出现了404代码（页面没有找到），说明在脚本中有错误的页面请求。具体的错误代码表示的意义，可以参考IIS的说明文档。

msnshow

5.3 Perf Counters

报表中还包含了所有性能计数器的信息。这些数据显示了运行时各个项目的测量值，同时还提供了最大值、最小值、平均值等。报表实际提供的信息远远超过了我们这里能够介绍的内容。

msnshow

5.4 Script Settings

这里显示的是运行本次测试时的设置，也就是前面讲到的Setting部分的内容。

5.5 Test Clients

这里显示的是各个WAS客户机的情况。先总体说明在测试中使用了那些WAS客户机，在使用的WAS客户机中显示

l 执行了多少线程

l 模拟了多少用户

l 点击的次数

l 连接失败的次数

msnshow

5.6 Page Summary

显示了在测试中各个请求内容的TTFB和TTLB，以及点击的次数等信息。具体的说明已经包含在5.1摘要中

5.7 Page Groups

显示不同的用户组在测试中的执行情况。这里提供的信息包括

l 用户组的分布情况，以及在所有用户组中所占的比例

l 点击的次数，以及在所有点击次数中所占的比例

l Result Codes情况

Socket连接的信息