搜索
使用WAS对Web应用程序压力测试WAS(MicrosoftWebApplicationStressTool,Web应用负载测试工具提供了一种简单的方法模拟大量用户来访问你的网站。这个工具能告诉我们你的Web应用程序工作时对硬件和软件的使用情况。在本文中我将告诉大家如何使用WAS,以及如何理解WAS测试的数据。1压力测试的必要性随着服务器端处理任务的日益复杂以及网站访问量的迅速增长,服务器性能的优化也成了非常迫切的任务。在优化之前,最好能够测试一下不同条件下服务器的性能表现。找出性能瓶颈所在是设计性能改善方案之前的一个至关紧要的步骤。负载测试是任何Web应用的开发周期中一个重要的步骤。如果你在构造一个为大量用户服务的应用,搞清楚你的产品配置能够承受多大的负载非常重要。如果你在构造一个小型的Intranet网站,测试能够暴露出最终会导致服务器崩溃的内存漏洞以及竞争情况。但是在实际的开发过程中,要按照实际投入运行的情况,组织成千上万的用户来进行压力测试,无论从那个方面看,都是不现实的。而且这样一旦发现了问题,不仅需要重复的进行这种耗费巨大的测试,而且问题不容易重现,不能方便的找出性能的瓶颈所在。而使用软件进行压力测试就不会存在这种情况。无论是哪种情形,花些时间对应用进行负载测试可以获得重要的基准性能数据,为未来的代码优化、硬件配置以及系统软件升级带来方便。即使经费有限的开发组织也可以对它们的网站进行负载测试,因为Microsoft的压力测试工具WAS是可以免费下载的。2WAS概要介绍为了有效的对Web应用程序进行压力测试,Microsoft发布了这个简单易用,功能强大的工具WAS。WAS要求WindowsNT4.0SP4或者更高,或者Windows2000。为了对网站进行负载测试,WAS可以通过一台或者多台客户机模拟大量用户的活动。WAS支持身份验证、加密和Cookies,也能够模拟各种浏览器类型和Modem速度,它的功能和性能可以与数万美元的产品相媲美。使用WAS时,为了更加接近真实的进行压力测试,我们推荐运行WAS的测试机和WebServer分开。3开始使用WAS要对网站进行负载测试首先必须创建WAS脚本模拟用户活动。我们可以用下面四种方法之一创建脚本:l通过记录浏览器的活动l通过导入IIS日志l通过把WAS指向Web网站的内容l手工制作在这里我们拿最常用的方法——通过记录浏览器的活动来讲解。其他三种方法在后面将会提到。3.1录制测试脚本打开菜单,选择Scripts|Create|Record创建一个测试脚本选取要记录的内容,有下面3种lRecorddelaybetweenrequest:记录了请求之间的延迟。由于用户实际上在浏览网站时,请求之间存在几秒甚至几分钟的延迟,这种录制方法在执行时会模仿用户之间的延迟发送请求,所以会是一个更加实际的测试。如果我们的目的是要发现Web应用程序的承受极限,就不要选择该项;如果只是想模拟一个特定数量的用户场景,那么选择该项进行测试捕捉请求延迟。lRecordbrowsercookies&Recordthehostheader:只记录用户的会话,不记录延迟时间。一般情况下,我们不需要选择这两项,可以让WAS创建cookies和hostheader,就好像用户登陆你的网站一样。然而,如果你有网站的回归信息时(比如一个用户的主要特征信息或者与一个永久性cookies相连的其他信息,在模拟一个新的用户登陆网站和进行必要的用户配置测试前,必须保证清除cookies,如果Web应用程序需要用户接受cookies,那么需要选中该选项。目前这个版本的WAS软件对基于浏览器IE录制脚本的方式还不支持HTTP/SSL请求。一般情况下,只选择后二种会增加压力的强度。根据压力测试实际的情况,选择合适的选项,然后点“Next|Finish”,WAS会打开一个IE窗口,在IE中输入要测试的站点地址,然后我们就可以按照实际的情况开始浏览站点了,浏览的同时也就是执行测试用例的过程。等测试用例执行完成后,切换到WAS窗口,点“StopRecording:”按钮,停止录制脚本WAS回到了视图页面,在该页面中你可以看到在录制过程中WAS收集的每一个链接,而且还可以编辑GET、POST以及HEAD信息。制作WAS脚本是相当简单的,不过要制作出模拟真实用户活动的脚本有点儿复杂。如果你已经有一个运行的Web网站,可以使用Web服务器的日志来确定Web网站上的用户点击分布。如果你的应用还没有开始运行,那么只好根据经验作一些猜测了。3.2负载参数设置测试脚本录制完成后,下一步我们要作的就是配置运行脚本的负载选项,我们可以调整测试配置以便观察不同条件下的应用性能。3.2.1ContentTree由于我们的WAS和WebServer是分开的,所以这里我们不需要设置3.2.2Setting(设置我们只要点击“Setting”就开始负载选项设置。1.ConCurrentConnections:StressLevel(threads的数值决定了所有客户机创建的Windows的线程的数值。每一个线程创建多个Socket连接(具体多少Socket连接数取决于Stressmultiplier(socketsperthread,每个Socket连接就是一个并发的请求(request。下面这个公式表示了它们之间的关系:总的并发请求数=StressLevel*Stressmultiplier=总的Socket连接数StressLevel和Stressmultiplier这二个项决定了访问服务器的并发连接的数量。Microsoft建议不要选择超过100的StressLevel值。如果要模拟的并发连接数量超过100个,可以调整Stressmultiplier或使用多个客户机。在负载测试期间WAS将通过DCOM与其他客户机协调。2.TestRunTime:设定持续运行多长时间的测试。我们可以在这里设定让WAS持续运行多少天、多少个小时、多少分钟、多少秒3.RequestDelay(inmilliseconds:设定请求延迟时间的最大、最小值,当然我们也可以选择“Userandomdelay”使用随机的延迟时间。一般情况下,我们常常会浏览一页,发现一个链接后,我们点击它。即便对该网站熟悉的人,4.Suspend:WAS允许设置warmup(热身时间,一般可以设置为1分钟。在warmup期间WAS开始执行脚本,但不收集统计数据。warmup时间给MTS、数据库以及磁盘缓冲等一个机会来做准备工作。如果在warmup时间内收集统计数据,这些操作的开销将影响性能测试结果。WAS也允许设置CoolDown时间。在WAS执行的时间达到设定的TestRunTime时,进入CoolDownTime,这时WAS并没有停止执行脚本,同样也不会收集统计数据。下图表示了它们的先后关系。WarmUp不收集统计数据TestRunTime收集统计数据CoolDown不收集统计数据5.Bandwith:设置页面提供的另外一个有用的功能是限制带宽(throttlebandwidth。带宽限制功能能够为测试模拟出Modem(14.kK,28.8K,56K、ISDN(64K,128K以及T1(1.54M的速度。使用带宽限制功能可以精确地预测出客户通过拨号网络或其他外部连接访问Web服务器所感受的性能。6.Redirects、Throughput、Nameresolution:这几个选项一般情况下采用默认情况即可。选中FollowHTTPredirects选项将会支持重定向。选中Throughput中的两项,WAS将会收集活动用户的cookies,以及收集网站的统计数字。默认情况下都会选中这两项,如果不选择,将会增加压力测试的强度。Nameresolution默认情况下没有选中。选中该选项,会让每一个客户测试机执行查询,只有在使用多个子网时才需要选中该项。(帮助原文:haveeachindividualtestclientperformalookup,thisisusefulwhenusingmultiplesubnets3.2.3PerfCounters(性能计数器使用WAS,从远程WindowsNT和Windows2000机器获取和分析性能计数器(PerformanceCounter是很方便的。加入计数器要用到下图所示的PerfCounters分枝。一般情况下,这里需要添加的性能计数器有:1WebServer:·处理器:CPU使用百分比(%CPUUtilization·内存:内存使用百分比(%MemoryUtilization·线程:每秒的上下文切换次数(ContextSwitchesPerSecond(Total·ASP:每秒请求数量(RequestsPerSecond·ASP:请求执行时间(RequestExecutionTime·ASP:请求等待时间(RequestWaitTime·ASP:置入队列的请求数量(RequestsQueued2各个WAS测试机·处理器:CPU使用百分比(%CPUUtilization·内存:内存使用百分比(%MemoryUtilization在测试中选择哪些计数器显然跟测试目的有关。虽然下面这个清单不可能精确地隔离出性能瓶颈所在,但对一般的Web服务器性能测试来说却是一个好的开始。•处理器:CPU使用百分比(%CPUUtilization•线程:每秒的上下文切换次数(ContextSwitchesPerSecond(Total•ASP:每秒请求数量(RequestsPerSecond•ASP:请求执行时间(RequestExecutionTime•ASP:请求等待时间(RequestWaitTime•ASP:置入队列的请求数量(RequestsQueuedCPU使用百分比反映了处理器开销。CPU使用百分比持续地超过75%是性能瓶颈在于处理器的一个明显的迹象。每秒上下文切换次数指示了处理器的工作效率。如果处理器陷于每秒数千次的上下文切换,说明它忙于切换线程而不是处理ASP脚本。每秒的ASP请求数量、执行时间以及等待时间在各种测试情形下都是非常重要的监测项目。每秒的请求数量告诉我们每秒内服务器成功处理的ASP请求数量。执行时间和等待时间之和显示了反应时间,这是服务器用处理好的页面作应答所需要的时间。我们可以绘出随着测试中并发用户数量的增加每秒请求数量和反应时间的变化图。增加并发用户数量时每秒请求数量也会增加。然而,我们最终会达到这样一个点,此时并发用户数量开始“压倒”服务器。如果继续增加并发用户数量,每秒请求数量开始下降,而反应时间则会增加。要搞清楚硬件和软件的能力,找出这个并发用户数量开始“压倒”服务器的临界点非常重要。置入队列的ASP请求数量也是一个重要的指标。如果在测试中这个数量有波动,某个COM对象所接收到的请求数量超过了它的处理能力。这可能是因为在应用的中间层使用了一个低效率的组件,或者在ASP会话对象中存储了一个单线程的单元组件。运行WAS的客户机CPU使用率也有必要监视。如果这些机器上的CPU使用率持续地超过75%,说明客户机没有足够的资源来正确地运行测试,此时应该认为测试结果不可信。在这种情况下,测试客户机的数量必须增加,或者减小测试的StressLevel。3.2.4PageGroups对于一个Web应用而言,同一时刻用户点击分布是不一样的。WAS允许设置用户点击流量的分布比例。这里我们假设在一个Web应用程序中,有650个人同时在线,其中100人正在添加提交数据,占15.38%;有150人正在查询,占23.08%。按照不同的Web应用,我们可以根据实际的情况在定制这个比例关系,来更加符合实际的情况。3.2.5Users现在很多Web应用程序为了提供个性化的服务,都设计了登陆过程。每个用户都有自己的登陆名和密码。WAS也考虑到了这种情况,我们只要在Users分支中添加用户名和对应的密码即可。3.2.6Clients添加多个WAS客户机