以便观察不同条件下的应用性能。图4是WAS的设置界面
【图4】
Stress Level和Stress multiplier这二个项决定了访问服务器的并发连接的数量。
Total Concurrent Requests = Stress level (threads) x Stress multiplier (sockets per thread) = Total Number Sockets
Microsoft建议不要选择超过100的Stress Level值。如果要模拟的并发连接数量超过100个，可以调整Stress multiplier或使用多个客户机。在负载测试期间WAS将通过
DCOM与其他客户机协调。有关在测试中使用多个客户机的更多信息，参见
如果网站提供个性化服务，要进行身份验证或使用Cookies，我们还要为WAS提供一个用户目录。WAS中的用户存储了发送给服务器的密码以及服务器 发送给客户端的Cookies。增加用户数量并不增加Web服务器的负载。必须提供足够数量的用户以满足并发连接的要求（Stesss Level乘以Stress Multiplier）。
设置随机延迟时间 在设置视图的Request Delay部分，你可以在执行测试前为每个脚本项选择加入随机延迟时间（或思考时间）。如果Use random delay选项框被选中，每个WAS线程会空转一段随机的时间（在最大值和最小值之间）加上为每个脚本项指定的固定的思考时间。
下面的公式解释了延迟时间的计算方法：
每项的延迟时间=随机延迟时间+每项的固定延迟时间
随机延迟时间的特性在固定延迟时间被指定给脚本项时尤为重要。如果没有使用随机延迟时间，所有的线程会在几乎相同的时间发送请求到Web服务器，然后等待几乎相同的固定延迟时间然后发送下一个请求。随机延迟时间在向Web服务器施加负载时有助于压平峰值和谷值，因此为所需的负载水平呈现一个更为精确的环境。
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服务器所感受的性能，例如如果绝大多数用户都是使用拨号上网的话，可以选择56K
指定其他设置
在设置视图的其他部分，我们保持默认值，除HTTP重定向外。我们故意去掉Follow HTTP redirects选项。这在创建脚本过程中你录制脚本时已经录制了URL的重定向的时候是必须的。你不需要重复两次地运行那些URL。
七、性能计算器
要理解这些不同的设置对应用的影响，有必要了解如何使用WAS收集性能数据。 使用WAS，从远程Windows NT和Windows 2000机器获取和分析性能计数器（Performance Counter）是很方便的。
1.在左边的窗口展开脚本的信息
2.在右边的窗口点Perf Counters节点打开相应的视图
3.在Collection Interval，输入收集时间间隔。这是以秒计算的取样时间。 4.点Add Counter按钮
5.从Add counter to report对话框，通过点Add按钮选机器，对象和你感兴趣收集的计数器。加入计数器要用到图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脚本是相当简单的，不过要制作出模拟真实用户活动的脚本有点儿复杂。如果你已经有一个运行的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在请求时随机选择变量值。这在一定程度上增加了脚本所模拟行为的真实性，也可以帮助避免缓冲对测试结果的影响准备好测试脚 本之后，我们可以调整测试配置。
九、指定用户
测试需要署名登录的Web站点时，WAS提供一个特性叫做Users，可用于存储多个用户的用户名，密码和cookie信息。 当一个测试开始时，所有的用户被分配到给定压力系数设置的各线程中。当请求开始时，每个线程使用从与该线程连接的共享池中获得的用户名，密码，和cookie。如果WAS配置的用户数比线程少，一些线程就会没有用户—所有的署名登录页面会登录取失败，任何与cookies的交互会被禁止。所以，当测试需要个人认证的网站时，拥有的用户数比线程多是很重要的。 对于可以在WAS中创建的用户数没有硬性的规定和限制。然而，因为每个用户都会需要一定的内存和资源，所以如果使用大量的用户，将会使你的测试启动和停止时间更长些。 创建新用户
1.在左边窗口展开脚本的信息