《应用WAS对web进行压力测试实例详解.docx》由会员分享，可在线阅读，更多相关《应用WAS对web进行压力测试实例详解.docx（7页珍藏版）》请在第壹文秘上搜索。
1、应用WAS对web进行压力测试实例详解本文介绍Microsoft的WebApplicationStressTool（WAS,Web应用负载测试工具）在Web服务器性能测试中的应用（注：Stress基本含义为“重压；压力”等，木文称之为“负载。另外，我们还将通过WAS评估一种相对简单的网站性能改善方法，这种方法的基本思想是在服务器上生成静态的HTML页面、避免过多的数据库调用。要对网站进行负载测试首先务必创建WAS脚本模拟用户活动。我们能够用下面四种方法之一创建脚本：通过记录浏览器的活动：通过导入IIS日志；通过把WAS指向Web网站的内容；或者者手工制作。图1所显示的是通过记录浏览器事件生成的
2、脚本的一部分，网站是Microsoft的DuwamishBkStOreoDuwamish是MiCrOSOft开发的电子商务Web应用示例，从DUWamiSh网站的“Phase4”链接可下列载这个软件包。下载包中包含了它自己的WAS测试脚本。【图1】通过记录浏览器事件生成的脚本制作WAS脚本是相当简单的，只是要制作出模拟真有用户活动的脚本有点儿复杂。假如你己经有一个运行的Web网站，能够使用Web服务器的口志来确定Web网站上的用户点击分布。假如你的应用还没有开始运行，那么只好根据经验作一些猜测了。图1这个脚本中我们假定有30个会员在浏览书店，同时又有一个会员正在购买。要模拟两者混合而成的行为，
3、首先务必创建页面组并在脚本的PageGroup分枝确定点击分布情况。在PageGrOUP分枝中我们能够增加、修改或者删除页面组，也能够为各个组修改流量的分布。图2显示了grp_browse与grp.buy这两个页面组与30比1的流量分布。-ioi F,ot aim f loMo A*tlv4l Wet AoMo SUoScvr IkoeNQnSCaPlCflB CooKl U -dbaf 【图2】grp_browse与grp_buy这两个页面组与30比1的流量分布创建了页面组之后,我们就能够在主脚本视图中给予各个请求不一致的页面组,如图3所示。为每个请求指定页面组相当于告诉WAS如何分布流量。
4、记住在木例中对grp_buy组页面的请求约占总数的3%,而对grp_browse组页面的请求约占97%。Edtc4t乂GVWirwSowHPflQl.befCMrtefP*9Gioupc56CWhr【图3】每个请求指定页面组相当于告诉WAS如何分布流量假如需要在查询字符串中传递“名字-值对，能够用WAS的查询字符串编辑器来定义各,ll-lfli个变量的所有可能的值。在输入变量值后，既能够要求WAS顺序地使用变量的各个值，也能够要求WAS在请求时随机选择变量值。这在一定程度上增加了脚本所模拟行为的真实性,也能够帮助避免缓冲对测试结果的影响准备好测试脚本之后，我们能够调整测试配置以便观察不一致条件
5、下的应用性能。图4是WAS的设置界面。WebApplicationStress-GAPcogramFiletXMiciosoKWebApplicationStt.詈EiteE&ScdphWeWWindoWHeIP:更 Sample Script Ulbaqff i-;曾 Duivwish图 Content Trc 卧 Settings 地 Perf COUnU 2 PdgeGroM ( Usen 曾 Cbenb Cookies【 P Uha-dbsiress;督 UItfdjxishMP W NewRecocdedrgIxbConcunenlConnectionsStfe5$level(Ihe
6、acfc)50Stressrmple*(socketsPefheH)1TestRunTimeDWI0H傕I0Mm:I_h5Sec:0Request(inmlrseconds)Userandomdelay.SuspetxiWarmup：Hir0MinsJ1Sec:0CooWown:H像I0MinsSec:0BandwithThfOKfetWrXMAhRedirectsPrFoIowHTTPredrectxMaoc15ThroughputPIheUSef$,PaWwOCd$,and如ecookiesPSavepageNa州khkRwdvEwotkIooktpsonremoteclientst-*I
7、人-ftj【图4】WAS的设置界面WAS同意设置WarmUP(热身)时间，通常能够设置为1分钟。在WannUP期间WAS开始执行脚本，但不收集统计数据。WarmUP时间给MTS、数据库与磁盘缓冲等一个机会来做准备工作。假如在WarmUP时间内收集统计数据，这些操作的开销将影响性能测试结果。设置页面提供的另外一个有用的功能是限制带宽(IhroiUebandwidih)。带宽限制功能能够为测试模拟出Modem(14.kK,28.8K,56K),ISDN(64K,128K)与Tl(1.54M)的速度。使用带宽限制功能能够精确地预测出客户通过拨号网络或者其他外部连接访问Web服务器所感受的性能。要懂得
8、这些不一致的设置对应用的影响，有必要熟悉如何使用WAS收集性能数据。使用WAS,从远程WindowsNT与Windows2000机器获取与分析性能计数器(PerformanceCounter)是很方便的。加入计数器要用到图5所示的PerfCounters分枝。【图5】PerfCounters分枝在测试中选择什么计数器显然跟测试目的有关。尽管下面这个清单不可能精确地隔离出性能瓶颈所在，但对通常的Web服务器性能测试来说却是一个好的开始。处理器：CPU使用百分比(%CPUUtilization)线程：每秒的上下文切换次数(COmeXtSWitCheSPerSeCOnd(TotaI) ASP：每秒请
9、求数量(ReqUeSlSPerSeCOnd) ASP：请求执行时间(ReqUeSlEXeCUliOnTime) ASP：请求等待时间(ReqlIeStWaitTime) ASP：置入队列的请求数量(RequestsQueued)CPU使用百分比反映了处理器开销。CPU使用百分比持续地超过75%是性能瓶颈在于处理器的一个明显的迹象。每秒上下文切换次数指示了处理器的工作效率。假如处理器陷于每秒数千次的上下文切换，说明它忙于切换线程而不是处理ASP脚本。每秒的ASP请求数量、执行时间与等待时间在各类测试情形下都是非常重要的监测项目。每秒的请求数量告诉我们每秒内服务器成功处理的ASP请求数量。执行时间
10、与等待时间之与显示了反应时间，这是服务器用处理好的页面作应答所需要的时间。置入队列的ASP请求数量也是一个重要的指标。假如在测试中这个数量有波动，某个COM对象所接收到的请求数量超过了它的处理能力。这可能是由于在应用的中间层使用了一个低效率的组件，或者者在ASP会话对象中存储了一个单线程的单元组件。运行WAS的客户机CPU使用率也有必要监视。假如这些机器上的CPU使用率持续地超过75%,说明客户机没有足够的资源来正确地运行测试，如今应该认为测试结果不可信。在这种情况下，测试客户机的数量务必增加，或者者减小测试的StreSSLeVe1。每次测试运行结束后WAS会生成全面的报表，即使测试被提早停止
11、也一样。WAS报表能够从View菜单选择Reports查看。下面介绍一下报表中几个重要的部分。假如这是一个新创建的测试脚本，你应该检查一下报表的ReSUItCOdeS部分。这部分内容包含了请求结果代码、说明与服务器返回的结果代码的数量。假如这里出现了404代码(页面没有找到)，说明在脚本中有错误的页面请求。页面摘要部分提供了页面的名字，接收到第一个字节的平均时间(TTFB),接收到最后一个字节的平均时间(TTLB),与测试脚本中各个页面的命中次数。TTFB与TTLB这两个值关于计算客户端所看到的服务器性能具有重要意义。TTFB反映了从发出页面请求到接收到应答数据第一个字节的时间总与（以亳秒计）
12、，TTLB包含了TTFB,它是客户机接收到页面最后一个字节所需要的累计时间。报表中还包含了所有性能计数器的信息。这些数据显示了运行时各个项目的测量值，同时还提供了最大值、最小值、平均值等。报表实际提供的信息远远超过了我们这里能够介绍的内容。为了给你一个有关表所提供信息种类的印象，图6摘录了一个报表实例。JLJ=JXLXlHI 1. .M.t.J: Wd .t4,t 3ir T wWS db : t , ：2zAtc* A 3 .H GtGrGCTGcrGtrw W 卬GcrGCT gR*ultGET dL3Bla/ ap?lvr9Min2$，h PercentiI$q?h Pexsndo1Jth Per cent & Ie WxILX 3 lt bvt (in *llco【图6】一个报表实例
