WAS性能测试说明书.docx

WAS性能测试说明书.docx

《WAS性能测试说明书.docx》由会员分享，可在线阅读，更多相关《WAS性能测试说明书.docx（19页珍藏版）》请在冰豆网上搜索。

WAS性能测试说明书

使用MicrosoftWebApplicationStressTool对web进行压力测试

      本文介绍Microsoft的WebApplicationStressTool（WAS，Web应用负载测试工具）在Web服务器性能测试中的应用。

另外，我们还将通过WAS评估一种相对简单的网站性能改善方法，这种方法的基本思想是在服务器上生成静态的HTML页面、避免过多的数据库调用。

一、WAS安装要求

WAS要求WindowsNT4.0SP4或者更高，或者Windows2000。

二、WAS的功能

为了对网站进行负载测试，WAS可以通过一台或者多台客户机模拟大量用户的活动。

WAS支持身份验证、加密和Cookies，也能够模拟各种浏览器类型和Modem速度

三、WAS测试准备

为了测试数据的准备性，首先需要删除缓存和Cookies等临时文件。

启动IE后打开“工具”菜单下的“Internet”选项命令，在打开的“Internet选项”窗口的“常规”选项卡中，单击“Internet临时文件”区域的“删除Cookies”和“删除文件”按钮将临时文件删除

四、录制测试脚本

要对网站进行负载测试首先必须创建WAS脚本模拟用户活动。

我们可以用下面四种方法之一创建脚本：

1、通过记录浏览器的活动；2、通过导入IIS日志；3、通过把WAS指向Web网站的内容；4、手工制作。

启动WAS，程序运行时会打开“Cteatenewscript”对话框，即建立一个新的脚本窗口（如图1），如果运行WAS没有打开该窗口可以单击WAS主程序窗口工具栏上第一个按钮“NewScript”即可。

图1

   因为是初次使用，所以在新建脚本窗口上单击“Record”按钮打开创建向导对话框“BrowserRecorder-Step1of2”，其中三个选项的作用是选择要记录的内容，分别为Request（请求）、Cookies（网上信息块）以及Hostheaders（主机标题），可根据需要选择（图2），然后单击“Next”即会打开“BrowserRecorder-Step2of2”窗口，单击“Finish”按钮。

这样WAS会自动启用，并且会打开一个浏览器窗口，此时我们就可以在浏览器的地址栏中输入要测试的网站网址。

随着要测试的网站内容的不断显示，在WAS主界面的“Recording”选项卡中的信息会实时更新（如图3）。

图2

图3

   当浏览器的状态栏显示为“完成”时，我们就可以返回WAS窗口，单击“StopRecording”按钮返回脚本窗口。

图1所显示的是通过记录浏览器事件生成的脚本的一部分，网站是Microsoft的DuwamishBookStore。

Duwamish是Microsoft开发的电子商务Web应用示例，从Duwamish网站的“Phase4”链接可以下载这个软件包。

下载包中包含了它自己的WAS测试脚本。

【图1】

五、修改脚本

   为了使测试更加准确，更加接按真实效果，需要对录制的测试脚本进行一些设置。

   由于网页是由图片、文字以及其它动态源码组成的，而一般的静态内容消耗的带宽并不是很大，因此我们可以将其排除在外。

还有删除延迟小的元素在脚本中选中指向图像、文字以及其它静态文件项目前的灰色按钮，然后单击工具栏上的“Delete”按钮将其删除（图4）。

图4

看录制的脚本是否为你所需要测试的服务器提供

查看地址域名是否错误，点击header会出现

为脚本项设置一系列的值

WAS允许你为一个脚本项的一对名字-值赋值，而不是对每一个请求都使用相同的值。

这个特性对于模拟真实情形很重要，没有用户会不停的以相同的数据值请求同一页面吧？

例如，其中一项测试脚本是请求一个ASP页面展示一个产品的详细信息。

我们可以设置WAS随机地从一列预先定义的产品ID选取不同的值，而不是每次都用相同的产品ID请求ASP页面。

为脚本项建立一列值

1.在WAS窗口的脚本项，双击脚本项最前面的方型按钮（在表单的第一列）打开这项的详细菜单。

2.在Querystring标签里（也叫QuerystringEditor,如Figure3所示），选定FormatdatatoCGIstandard。

相应的名字-值对会出现在checkbox下的表单里。

3.点选定的名字-值对的值，一个新的按钮会出现

4.点这个按钮打开FieldValues对话框

5.在Fieldvalues对话框输入一串值，每一行一个值。

你也可以通过剪切，粘贴一个电子表格的数据文件来输入。

6.在QuerystringEditor里，在表单中点有相同名字-值对的Distribution一列。

在下拉菜单选择Random。

为脚本项设置SSL

为特定的脚本项激活SSL，需要作以下操作：

1.在WAS窗口的脚本项，双击脚本项最前面的方型按钮（在表单的第一列）打开这项的详细菜单。

2.在SSL标签里，选UseSSL.（注意在你激活SSL时确保端口值应该在80到443之间）。

六、测试参数设置

以便观察不同条件下的应用性能。

图4是WAS的设置界面

【图4】

      StressLevel和Stressmultiplier这二个项决定了访问服务器的并发连接的数量。

TotalConcurrentRequests=Stresslevel（threads）xStressmultiplier

（socketsperthread）=TotalNumberSockets

Microsoft建议不要选择超过100的StressLevel值。

如果要模拟的并发连接数量超过100个，可以调整Stressmultiplier或使用多个客户机。

在负载测试期间WAS将通过DCOM与其他客户机协调。

有关在测试中使用多个客户机的更多信息，参见

　　如果网站提供个性化服务，要进行身份验证或使用Cookies，我们还要为WAS提供一个用户目录。

WAS中的用户存储了发送给服务器的密码以及服务器发送给客户端的Cookies。

增加用户数量并不增加Web服务器的负载。

必须提供足够数量的用户以满足并发连接的要求（StesssLevel乘以StressMultiplier）。

设置随机延迟时间

在设置视图的RequestDelay部分，你可以在执行测试前为每个脚本项选择加入随机延迟时间（或思考时间）。

如果Userandomdelay选项框被选中，每个WAS线程会空转一段随机的时间（在最大值和最小值之间）加上为每个脚本项指定的固定的思考时间。

下面的公式解释了延迟时间的计算方法：

每项的延迟时间=随机延迟时间+每项的固定延迟时间

随机延迟时间的特性在固定延迟时间被指定给脚本项时尤为重要。

如果没有使用随机延迟时间，所有的线程会在几乎相同的时间发送请求到Web服务器，然后等待几乎相同的固定延迟时间然后发送下一个请求。

随机延迟时间在向Web服务器施加负载时有助于压平峰值和谷值，因此为所需的负载水平呈现一个更为精确的环境。

　　WAS允许设置warmup（热身）时间，一般可以设置为1分钟。

在warmup期间WAS开始执行脚本，但不收集统计数据。

warmup时间给MTS、数据库以及磁盘缓冲等一个机会来做准备工作。

如果在warmup时间内收集统计数据，这些操作的开销将影响性能测试结果。

　　设置页面提供的另外一个有用的功能是限制带宽（throttlebandwidth）。

带宽限制功能能够为测试模拟出Modem（14.kK，28.8K，56K）、ISDN（64K，128K）以及T1（1.54M）的速度。

使用带宽限制功能可以精确地预测出客户通过拨号网络或其他外部连接访问Web服务器所感受的性能，例如如果绝大多数用户都是使用拨号上网的话，可以选择56K

指定其他设置

在设置视图的其他部分，我们保持默认值，除HTTP重定向外。

我们故意去掉FollowHTTPredirects选项。

这在创建脚本过程中你录制脚本时已经录制了URL的重定向的时候是必须的。

你不需要重复两次地运行那些URL。

七、性能计算器　　

要理解这些不同的设置对应用的影响，有必要了解如何使用WAS收集性能数据。

使用WAS，从远程WindowsNT和Windows2000机器获取和分析性能计数器（PerformanceCounter）是很方便的。

1.在左边的窗口展开脚本的信息

2.在右边的窗口点PerfCounters节点打开相应的视图

3.在CollectionInterval，输入收集时间间隔。

这是以秒计算的取样时间。

4.点AddCounter按钮

5.从Addcountertoreport对话框，通过点Add按钮选机器，对象和你感兴趣收集的计数器。

加入计数器要用到图5所示的PerfCounters分枝。

   【图5】

      在测试中选择哪些计数器显然跟测试目的有关。

虽然下面这个清单不可能精确地隔离出性能瓶颈所在，但对一般的Web服务器性能测试来说却是一个好的开始。

      ·处理器：

CPU使用百分比（%CPUUtilization）

      ·线程：

每秒的上下文切换次数（ContextSwitchesPerSecond（Total））

      ·ASP：

每秒请求数量（RequestsPerSecond）

      ·ASP：

请求执行时间（RequestExecutionTime）

      ·ASP：

请求等待时间（RequestWaitTime）

      ·ASP：

置入队列的请求数量（RequestsQueued）

　　CPU使用百分比反映了处理器开销。

CPU使用百分比持续地超过75%是性能瓶颈在于处理器的一个明显的迹象。

每秒上下文切换次数指示了处理器的工作效率。

如果处理器陷于每秒数千次的上下文切换，说明它忙于切换线程而不是处理ASP脚本。

     每秒的ASP请求数量、执行时间以及等待时间在各种测试情形下都是非常重要的监测项目。

每秒的请求数量告诉我们每秒内服务器成功处理的ASP请求数量。

执行时间和等待时间之和显示了反应时间，这是服务器用处理好的页面作应答所需要的时间。

　　我们可以绘出随着测试中并发用户数量的增加每秒请求数量和反应时间的变化图。

增加并发用户数量时每秒请求数量也会增加。

然而，我们最终会达到这样一个点，此时并发用户数量开始“压倒”服务器。

如果继续增加并发用户数量，每秒请求数量开始下降，而反应时间则会增加。

要搞清楚硬件和软件的能力，找出这个并发用户数量开始“压倒”服务器的临界点非常重要。

　　置入队列的ASP请求数量也是一个重要的指标。

如果在测试中这个数量有波动，某个COM对象所接收到的请求数量超过了它的处理能力。

这可能是因为在应用的中间层使用了一个低效率的组件，或者在ASP会话对象中存储了一个单线程的单元组件。

　　运行WAS的客户机CPU使用率也有必要监视。

如果这些机器上的CPU使用率持续地超过75%，说明客户机没有足够的资源来正确地运行测试，此时应该认为测试结果不可信。

在这种情况下，测试客户机的数量必须增加，或者减小测试的StressLevel。

八、建立页面组和点击百分比

制作WAS脚本是相当简单的，不过要制作出模拟真实用户活动的脚本有点儿复杂。

如果你已经有一个运行的Web网站，可以使用Web服务器的日志来确定Web网站上的用户点击分布。

如果你的应用还没有开始运行，那么只好根据经验作一些猜测了。

　　图1这个脚本中我们假定有