应用WAS对web进行压力测试实例详解.doc

《应用WAS对web进行压力测试实例详解.doc》由会员分享，可在线阅读，更多相关《应用WAS对web进行压力测试实例详解.doc（7页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、应用WAS对web进行压力测试实例详解你的Web服务器和应用到底能够支持多少并发用户访问？在出现大量并发请求的情况下，软件会出现问题吗？这些问题靠通常的测试手段是无法解答的。本文介绍了Microsoft为这个目的而提供的免费工具WAS及其用法。另外，本文介绍了一种Web应用的性能优化方法，并利用WAS测试了它的性能改善程度。本文介绍Microsoft的Web Application Stress Tool（WAS，Web应用负载测试工具）在Web服务器性能测试中的应用（注：Stress基本含义为“重压；压力”等，本文称之为“负载”）。另外，我们还将通过WAS评估一种相对简单的网站性能改善方法，

2、这种方法的基本思想是在服务器上生成静态的HTML页面、避免过多的数据库调用。 要对网站进行负载测试首先必须创建WAS脚本模拟用户活动。我们可以用下面四种方法之一创建脚本：通过记录浏览器的活动；通过导入IIS日志；通过把WAS指向Web网站的内容；或者手工制作。图1所显示的是通过记录浏览器事件生成的脚本的一部分，网站是Microsoft的Duwamish Book Store。Duwamish是Microsoft开发的电子商务Web应用示例，从Duwamish网站的“Phase 4”链接可以下载这个软件包。下载包中包含了它自己的WAS测试脚本。 【图1】 通过记录浏览器事件生成的脚本制作WAS脚

3、本是相当简单的，不过要制作出模拟真实用户活动的脚本有点儿复杂。如果你已经有一个运行的Web网站，可以使用Web服务器的日志来确定Web网站上的用户点击分布。如果你的应用还没有开始运行，那么只好根据经验作一些猜测了。 图1这个脚本中我们假定有30个会员在浏览书店，同时又有一个会员正在购买。要模拟两者混合而成的行为，首先必须创建页面组并在脚本的Page Group分枝确定点击分布情况。在Page Group分枝中我们可以增加、修改或删除页面组，也可以为各个组修改流量的分布。 图2显示了grp_browse和grp_buy这两个页面组以及30比1的流量分布。 【图2】grp_browse和grp_b

4、uy这两个页面组以及30比1的流量分布创建了页面组之后，我们就可以在主脚本视图中赋予各个请求不同的页面组，如图3所示。为每个请求指定页面组相当于告诉WAS如何分布流量。记住在本例中对grp_buy组页面的请求约占总数的3%，而对grp_browse组页面的请求约占97%。 【图3】每个请求指定页面组相当于告诉WAS如何分布流量如果需要在查询字符串中传递“名字-值”对，可以用WAS的查询字符串编辑器来定义各个变量的所有可能的值。在输入变量值后，既可以要求WAS顺序地使用变量的各个值，也可以要求WAS在请求时随机选择变量值。这在一定程度上增加了脚本所模拟行为的真实性，也可以帮助避免缓冲对测试结果的

5、影响准备好测试脚本之后，我们可以调整测试配置以便观察不同条件下的应用性能。图4是WAS的设置界面。【图4】WAS的设置界面Stress Level和Stress multiplier这二个项决定了访问服务器的并发连接的数量。Microsoft建议不要选择超过100的Stress Level值。如果要模拟的并发连接数量超过100个，可以调整Stress multiplier或使用多个客户机。在负载测试期间WAS将通过DCOM与其他客户机协调。有关在测试中使用多个客户机的更多信息，参见 如果网站提供个性化服务，要进行身份验证或使用Cookies，我们还要为WAS提供一个用户目录。WAS中的用户存储

6、了发送给服务器的密码以及服务器发送给客户端的Cookies。增加用户数量并不增加Web服务器的负载。必须提供足够数量的用户以满足并发连接的要求（Stesss Level乘以Stress Multiplier）。有关线程、用户、Cookies相互作用的更多信息请参见 WAS允许设置warmup（热身）时间，一般可以设置为1分钟。在warmup期间WAS开始执行脚本，但不收集统计数据。warmup时间给MTS、数据库以及磁盘缓冲等一个机会来做准备工作。如果在warmup时间内收集统计数据，这些操作的开销将影响性能测试结果。 设置页面提供的另外一个有用的功能是限制带宽（throttle bandwi

7、dth）。带宽限制功能能够为测试模拟出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】Perf Counters分枝在测试中选择哪些计数器显然跟测试目的有关。

8、虽然下面这个清单不可能精确地隔离出性能瓶颈所在，但对一般的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%是性能瓶颈

9、在于处理器的一个明显的迹象。每秒上下文切换次数指示了处理器的工作效率。如果处理器陷于每秒数千次的上下文切换，说明它忙于切换线程而不是处理ASP脚本。 每秒的ASP请求数量、执行时间以及等待时间在各种测试情形下都是非常重要的监测项目。每秒的请求数量告诉我们每秒内服务器成功处理的ASP请求数量。执行时间和等待时间之和显示了反应时间，这是服务器用处理好的页面作应答所需要的时间。 置入队列的ASP请求数量也是一个重要的指标。如果在测试中这个数量有波动，某个COM对象所接收到的请求数量超过了它的处理能力。这可能是因为在应用的中间层使用了一个低效率的组件，或者在ASP会话对象中存储了一个单线程的单元组件。

10、运行WAS的客户机CPU使用率也有必要监视。如果这些机器上的CPU使用率持续地超过75%，说明客户机没有足够的资源来正确地运行测试，此时应该认为测试结果不可信。在这种情况下，测试客户机的数量必须增加，或者减小测试的Stress Level。 每次测试运行结束后WAS会生成详细的报表，即使测试被提前停止也一样。WAS报表可以从View菜单选择Reports查看。下面介绍一下报表中几个重要的部分。 如果这是一个新创建的测试脚本，你应该检查一下报表的Result Codes部分。这部分内容包含了请求结果代码、说明以及服务器返回的结果代码的数量。如果这里出现了404代码（页面没有找到），说明在脚本中有

11、错误的页面请求。 页面摘要部分提供了页面的名字，接收到第一个字节的平均时间（TTFB），接收到最后一个字节的平均时间（TTLB），以及测试脚本中各个页面的命中次数。TTFB和TTLB这两个值对于计算客户端所看到的服务器性能具有重要意义。TTFB反映了从发出页面请求到接收到应答数据第一个字节的时间总和（以毫秒计），TTLB包含了TTFB，它是客户机接收到页面最后一个字节所需要的累计时间。 报表中还包含了所有性能计数器的信息。这些数据显示了运行时各个项目的测量值，同时还提供了最大值、最小值、平均值等。报表实际提供的信息远远超过了我们这里能够介绍的内容。为了给你一个有关表所提供信息种类的印象，图6摘录了一个报表实例。 【图6】一个报表实例