WAS 服务器负载测试软件使用说明

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 上花费一些时间，你就能够更深入地了解你的应用的性能、稳定性、瓶颈和局限性。花费这种时间是值得的。