WAS
服务器负载测试软件使用说明
（
Microsoft Web Application Stress Tool
）
一、建立新脚本
方法一、启动
WAS
软件后会自动显示建立新脚本的提示页面，选择
[manual]
按钮就可完成建立新脚本的功能。
方法二、启动
WAS
软件后点击
[new script]
按钮。
二、编辑脚本内容
1
、在选择脚本名称的右侧会出现相应的设置
[server]
中输入要进行测试的服务器
IP
地址或计算机名称；
[verb]
中选择脚本运行方式
get
、
post
、
head
；
[path]
中输入向服务器提交的文件或字符串。
2
、
[content tree]
该项在默认情况下不做更改。
3
、
[settings]
设置测试持续时间
在
“test run time”
各项中输入相应数字即可。
4
、
[perf counters]
该项在默认情况下不做更改。
5
、
[page groups]
该项在默认情况下不做更改。
6
、
[users]
选项下双击
[default]
或单击
[show users]
快捷键进入用户设置页面。
在
[user name]
和
[password]
中输入服务器认可的用户和密码，点击
[create]
按钮完成
添加用户功能。
删除用户时只需要点中用户左侧按钮选中该行后点击
[
删除
]
快捷键。
[number of new]
项不能设为
“0”
，否则添加无效。
7
、
[clients]
双击
[default]
进入设置页面
在
[machine]
输入添加客户的计算机名后点击
[add]
按钮，在默认状态下只有
“localhost”
客户连接，添加的其他客户均离线。选中的客户会在报告中显示。
8
、
[cookies]
自动显示用户的状态。
三、
web
测试
1
、选择运行脚本名称
2
、在
[script]
菜单中选择
[run]
或者点击
[
运行脚本
]
快捷键
四、测试报告
1
、点击
[report]
快捷键出现报告目录
2
、选择脚本名称以及详细测试时间文件
说明：
TTFB
表示从请求开始到
WAS
收到的时间
TTLB
表示最后一个请求从
WAS
反馈到客户端的时间
五、删除脚本
选择要删除的脚本名称后点击
[
删除
]
快捷键
六、菜单说明
1
、
[file]
下的
[new]
初始化
WAS
软件，并非新建立；
2
、
[file]
下的
[open]
打开以前保存的文件。
WAS
服务器负载测试软件导读
你的
Web
服务器和应用到底能够支持多少并发用户访问？在出现大量并发请求的情况下，软件会出现问题吗？这些问题靠通常的测试手段是无法解答的。本文介绍了
Microsoft
为这个目的而提供的免费工具
WAS
及其用法。另外，本文介绍了一种
Web
应用的性能优化方法，并利用
WAS
测试了它的性能改善程度。原文出处：
[url]http://www.asptoday.com/articles/20000420.htm[/url]
编译如下：
随着服务器端处理任务的日益复杂以及网站访问量的迅速增长，服务器性能的优化也成了非常迫切的任务。在优化之前，最好能够测试一下不同条件下服务器的性能表现。找出性能瓶颈所在是设计性能改善方案之前的一个至关紧要的步骤。
本文介绍
Microsoft
的
Web Application Stress Tool
（
WAS
，
Web
应用负载测试工具）在
Web
服务器性能测试中的应用（注：
Stress
基本含义为
“
重压；压力
”
等，本文称之为
“
负载
”
）。另外，我们还将通过
WAS
评估一种相对简单的网站性能改善方法，这种方法的基本思想是在服务器上生成静态的
HTML
页面、避免过多的数据库调用。
负载测试是任何
Web
应用的开发周期中一个重要的步骤。如果你在构造一个为大量用户服务的应用，搞清楚你的产品配置能够承受多大的负载非常重要。如果你在构造一个小型的
Intranet
网站，测试能够暴露出最终会导致服务器崩溃的内存漏洞以及竞争情况。
无论是哪种情形，花些时间对应用进行负载测试可以获得重要的基准性能数据，为未来的代码优化、硬件配置以及系统软件升级带来方便。即使经费有限的开发组织也可以对它们的网站进行负载测试，因为
Microsoft
的
WAS
是可以免费下载的。
WAS
要求
Windows NT 4.0 SP4
或者更高，或者
Windows 2000
。为了对网站进行负载测试，
WAS
可以通过一台或者多台客户机模拟大量用户的活动。
WAS
支持身份验证、加密和
Cookies
，也能够模拟各种浏览器类型和
Modem
速度，它的功能和性能可以与数万美元的产品相媲美。如果你对
WAS
和
Microsoft
的另外一个测试工具
Web Capacity Analysis Tool
（
WCAT
）之间的差别感兴趣，可以访问
Microsoft Web
工具的比较页面。
要对网站进行负载测试首先必须创建
WAS
脚本模拟用户活动。我们可以用下面四种方法之一创建脚本：通过记录浏览器的活动；通过导入
IIS
日志；通过把
WAS
指向
Web
网站的内容；或者手工制作。图
1
所显示的是通过记录浏览器事件生成的脚本的一部分，网站是
Microsoft
的
Duwamish Book Store
。
Duwamish
是
Microsoft
开发的电子商务
Web
应用示例，从
Duwamish
网站的
“Phase 4”
链接可以下载这个软件包。下载包中包含了它自己的
WAS
测试脚本。
【图
1
】
制作
WAS
脚本是相当简单的，不过要制作出模拟真实用户活动的脚本有点儿复杂。如果你已经有一个运行的
Web
网站，可以使用
Web
服务器的日志来确定
Web
网站上的用户点击分布。如果你的应用还没有开始运行，那么只好根据经验作一些猜测了。
图
1
这个脚本中我们假定有
30
个会员在浏览书店，同时又有一个会员正在购买。要模拟两者混合而成的行为，首先必须创建页面组并在脚本的
Page Group
分枝确定点击分布情况。在
Page Group
分枝中我们可以增加、修改或删除页面组，也可以为各个组修改流量的分布。
图
2
显示了
grp_browse
和
grp_buy
这两个页面组以及
30
比
1
的流量分布。
【图
2
】
创建了页面组之后，我们就可以在主脚本视图中赋予各个请求不同的页面组，如图
3
所示。为每个请求指定页面组相当于告诉
WAS
如何分布流量。记住在本例中对
grp_buy
组页面的请求约占总数的
3%
，而对
grp_browse
组页面的请求约占
97%
。
【图
3
】
如果需要在查询字符串中传递
“
名字
-
值
”
对，可以用
WAS
的查询字符串编辑器来定义各个变量的所有可能的值。在输入变量值后，既可以要求
WAS
顺序地使用变量的各个值，也可以要求
WAS
在请求时随机选择变量值。这在一定程度上增加了脚本所模拟行为的真实性，也可以帮助避免缓冲对测试结果的影响
准备好测试脚本之后，我们可以调整测试配置以便观察不同条件下的应用性能。图
4
是
WAS
的设置界面。
【图
4
】
Stress Level
和
Stress multiplier
这二个项决定了访问服务器的并发连接的数量。
Microsoft
建议不要选择超过
100
的
Stress Level
值。如果要模拟的并发连接数量超过
100
个，可以调整
Stress multiplier
或使用多个客户机。在负载测试期间
WAS
将通过
DCOM
与其他客户机协调。有关在测试中使用多个客户机的更多信息，参见
[url]http://webtool.rte.microsoft.com/kb/hkb13.htm[/url]
。
如果网站提供个性化服务，要进行身份验证或使用
Cookies
，我们还要为
WAS
提供一个用户目录。
WAS
中的用户存储了发送给服务器的密码以及服务器发送给客户端的
Cookies
。增加用户数量并不增加
Web
服务器的负载。必须提供足够数量的用户以满足并发连接的要求（
Stesss Level
乘以
Stress Multiplier
）。有关线程、用户、
Cookies
相互作用的更多信息请参见
[url]http://webtool.rte.microsoft.com/Threads/WASThreads.htm[/url]
。
WAS
允许设置
warmup
（热身）时间，一般可以设置为
1
分钟。在
warmup
期间
WAS
开始执行脚本，但不收集统计数据。
warmup
时间给
MTS
、数据库以及磁盘缓冲等一个机会来做准备工作。如果在
warmup
时间内收集统计数据，这些操作的开销将影响性能测试结果。
设置页面提供的另外一个有用的功能是限制带宽（
throttle bandwidth
）。带宽限制功能能够为测试模拟出
Modem
（
14.k K
，
28.8 K
，
56 K
）、
ISDN
（
64 K
，
128 K
）以及
T1
（
1.54 M
）的速度。使用带宽限制功能可以精确地预测出客户通过拨号网络或其他外部连接访问
Web
服务器所感受的性能。
要理解这些不同的设置对应用的影响，有必要了解如何使用
WAS
收集性能数据。
使用
WAS
，从远程
Windows NT
和
Windows 2000
机器获取和分析性能计数器（
Performance Counter
）是很方便的。加入计数器要用到图
5
所示的
Perf Counters
分枝。
【图
5
】
在测试中选择哪些计数器显然跟测试目的有关。虽然下面这个清单不可能精确地隔离出性能瓶颈所在，但对一般的
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
。
每次测试运行结束后
WAS
会生成详细的报表，即使测试被提前停止也一样。
WAS
报表可以从
View
菜单选择
Reports
查看。下面介绍一下报表中几个重要的部分。
如果这是一个新创建的测试脚本，你应该检查一下报表的
Result Codes
部分。这部分内容包含了请求结果代码、说明以及服务器返回的结果代码的数量。如果这里出现了
404
代码（页面没有找到），说明在脚本中有错误的页面请求。
页面摘要部分提供了页面的名字，接收到第一个字节的平均时间（
TTFB
），接收到最后一个字节的平均时间（
TTLB
），以及测试脚本中各个页面的命中次数。
TTFB
和
TTLB
这两个值对于计算客户端所看到的服务器性能具有重要意义。
TTFB
反映了从发出页面请求到接收到应答数据第一个字节的时间总和（以毫秒计），
TTLB
包含了
TTFB
，它是客户机接收到页面最后一个字节所需要的累计时间。
报表中还包含了所有性能计数器的信息。这些数据显示了运行时各个项目的测量值，同时还提供了最大值、最小值、平均值等。报表实际提供的信息远远超过了我们这里能够介绍的内容。为了给你一个有关表所提供信息种类的印象，图
6
摘录了一个报表实例。
【图
6
】
随着
Internet
应用的日益广泛，用户的要求和期望也在不断地发展。今天的客户期待个性化的可定制的方案，期待这些方案不仅简单，而且快速、可靠、成本低廉。对于能够适应用户需求不断变动的可定制页面来说，静态
HTML
已经退出了舞台，比如内容根据客户请求变化的页面就是其中一例。这一切都要求系统保存相关的数据，例如有关用户本身以及用户可能请求哪些信息的数据。
紧跟这些趋势的
Web
开发者已经开始提供可定制的
Web
网站。象搜索数据之类的任务现在可以由服务器执行而无需客户干预。然而，这些变革也导致了一个结果，这就是许多网站都在使用大量的未经优化的数据库调用，从而使得应用性能大打折扣。
我们可以使用以下几种方法来解决这些问题：
1.
优化
ASP
代码。
2.
优化数据库调用。
3.
使用存储过程。
4.
调整服务器性能。
优秀的网站设计都会关注这些问题。然而，与静态页面的速度相比，任何数据库调用都会显著地影响
Web
网站的响应速度，这主要是因为在发送页面之前必须单独地为每个访问网站的用户进行数据库调用。
这里提出的性能优化方案正是基于以下事实：访问静态
HTML
页面要比访问那些内容依赖于数据库调用的页面要快。它的基本思想是：在用户访问页面之前，预先从数据库提取信息写入存储在服务器上的静态
HTML
页面。为了保证这些静态页面能够及时地反映不断变化的数据库数据，必须有一个调度程序管理静态页面的生成。
当然，这种方案并不能够适应所有的情形。例如，如果是从持续变化的大容量数据库提取少量信息，这种方案是不合适的。不过可以适用该方案的场合还是很多。
为了保证能够在合适的时间更新静态
HTML
页面，把下面的代码加入到相应的
ASP
页面前面：
< %
lastUpdated=Application("LastUpdated")
presentTime=now
if DATEDIFF("h",lastUpdated,presentTime) >= 1 then
Application ("LastUpdated") =presentTime
response.redirect
"Update.asp?physicalpath="&Request.ServerVariables("PATH_TRANSLATED")
end if
% >
< html >
Static content goes here
< /html >
每当该页面被调用，脚本就会提取最后的更新时间并将它与当前时间比较。如果两个时间之间的差值大于预定的数值，
Update.asp
脚本就会运行；否则，该
ASP
页面把余下的
HTML
代码发送给浏览器。
最后更新时间从
Application
变量得到，它的第一次初始化由
global.asa
完成。具体的更新时间间隔应根据页面内容的更新要求调整。
如果每次访问
ASP
页面的时候都要提供最新的信息，或者输出与用户输入密切相关，这种方法并不实用，但这种方法可以适应以固定的时间间隔更新信息的场合。
如果数据库内容由客户通过适当的
ASP
页面更新，要确保静态页面也能够自动反映数据的变化，我们可以在
ASP
页面中调用
Update
脚本。这样，每当数据库内容改变时服务器上也有了最新的静态
HTML
页面。
另一种处理频繁变动数据的办法是借助
Microsft SQL Server 7.0
的
Web
助手向导（
Web Assistant Wizard
），这个向导能够利用
Transact-SQL
、存储过程等从
SQL Server
数据生成标准的
HTML
文件。
利用
SQL Server
任务，
Web
助手向导能够用来定期地生成
HTML
页面。正如前面概要介绍的方案，
Web
助手可以通过触发子更新
HTML
页面，比如在指定的时间执行更新或者在数据库数据变化时执行更新。
SQL Server
使用名为
sp_makewebtask
的存储过程创建
HTML
页面，它的参数是目标
HTML
文件的名字和待执行存储过程的名字，查询的输出发送到
HTML
页面。另外，也可以选择使用可供结果数据插入的模板文件。
从前面的代码可以看出，当
ASP
页面
HtmlMain.asp
需要更新时，控制以
ASP
文件的物理路径为参数转到了
Update
页面。
Update
脚本的任务是用新的
HTML
数据刷新发出调用的
ASP
文件，并把调度
ASP
代码加入到文件的开头。为此，
Update
脚本打开调度模板文件，拷贝调度
ASP
代码，然后控制转到了另一部分脚本，这部分脚本主要任务是执行数据库操作。
Update
用路径参数以写模式打开
HtmlMain.asp
文件，数据库操作的输出以
HTML
格式写入这个文件。
万一用户访问页面的时候正好在执行更新，我们可以利用锁或者其他类似的机制把页面延迟几秒钟。
HtmlMain.asp
（纯
HTML
加调度
ASP
代码）和
main.asp
（普通的
ASP
文件）在
WAS
下进行了性能测试。
main.asp
文件要查找
5
个不同的表为页面提取数据。为了和这两个文件相比较，一个只访问单个表的
ASP
页面（
SingleTableTest.asp
）和一个纯
HTML
文件（
PlainHtml.html
）也进行了测试。
测试结果如下表所示：
文件名字
命中数
平均
TTFB
（
ms
）
平均
TTLB
（
ms
）
PlainHtml.html 8 47 474
SingleTableTest.asp 8 68.88 789.38
Main.asp 9 125.89 3759.56
HtmlMain.asp 9 149.89 1739.89
其中
TTFB
是指
Total Time to First Byte
，
TTLB
是指
Total Time to Last Byte
。
这些测试在一台
Windows NT Workstation 4.0 SP6
运行
Personal Web Server
的机器上实施。为了使性能指标更明显，带宽限制到了
14.4 K
。在实际环境中数值变化可能很大，但这个结果精确地反映了各个页面在性能上的差异。
测试结果显示访问单个表的
ASP
页面的处理时间是
720.5ms
，而纯
HTML
文件则为
427ms
。
Main.asp
和
HtmlMain.asp
的输出时间相同，但它们的处理时间分别为
3633.67ms
和
1590ms
。也就是说，在这个测试环境下我们可以把处理速度提高
43%
。
如果我们要让页面每隔一定的访问次数更新，比如
100
次，那么这第
100
个用户就必须等待新的
HTML
页面生成。不过，这个代价或许不算太高，其他
99
个用户获得了好处。
静态页面方法并不能够适合所有类型的页面。例如，某些页面在进行任何处理之前必须要有用户输入。但是，这种方法可以成功地应用到那些不依赖用户输入却进行大量数据库调用的页面，而且这种情况下它将发挥出更大的效率。
在大多数情况下，动态页面的生成将在相当大的程度上提高网站的性能而且无需在功能上有所折衷。虽然有许多大的网站采用了这个策略来改善性能，也有许多网站完全由于进行大量没有必要的数据库调用而表现出很差的性能。
Microsoft
的
WAS
是一个功能非常丰富的服务器性能测试工具，可以帮助我们准确地判断什么方案将适合于提升网站性能；是否某个方案（比如本文第二部分的静态页面方案）能够显著地改善性能。
本文对
WAS
的介绍应当说是相当粗略和肤浅的。
WAS
还提供了一个对象模型，我们可以通过脚本扩展它的功能。访问
[url]http://webtool.rte.microsoft.com/?ObjModel/default.htm[/url]
可以看到一个脚本示例。这个脚本将登记
Web
服务器的每秒最大请求数量，自动地增加
Stress Level
值直到服务器处理器利用率达到
90%
为止。
WAS
能够为你提供有关
ASP
应用和它所运行的硬件的丰富的信息。在
WAS
上花费一些时间，你就能够更深入地了解你的应用的性能、稳定性、瓶颈和局限性。花费这种时间是值得的。