使用Microsoft Web Application Stress Tool对web进行压力测试

使用MicrosoftWebApplicationStressTool对web进行压力测试

你的Web服务器和应用到底能够支持多少并发用户访问？在出现大量并发请求的情况下，软件会出现问题吗？这些问题靠通常的测试手段是无法解答的。本文介绍了Microsoft为这个目的而提供的免费工具WAS及其用法。另外，本文介绍了一种Web应用的性能优化方法，并利用WAS测试了它的性能改善程度。

随着服务器端处理任务的日益复杂以及网站访问量的迅速增长，服务器性能的优化也成了非常迫切的任务。在优化之前，最好能够测试一下不同条件下服务器的性能表现。找出性能瓶颈所在是设计性能改善方案之前的一个至关紧要的步骤。

本文介绍Microsoft的WebApplicationStressTool（WAS，Web应用负载测试工具）在Web服务器性能测试中的应用（注：Stress基本含义为“重压；压力”等，本文称之为“负载”）。另外，我们还将通过WAS评估一种相对简单的网站性能改善方法，这种方法的基本思想是在服务器上生成静态的HTML页面、避免过多的数据库调用。

负载测试是任何Web应用的开发周期中一个重要的步骤。如果你在构造一个为大量用户服务的应用，搞清楚你的产品配置能够承受多大的负载非常重要。如果你在构造一个小型的Intranet网站，测试能够暴露出最终会导致服务器崩溃的内存漏洞以及竞争情况。

无论是哪种情形，花些时间对应用进行负载测试可以获得重要的基准性能数据，为未来的代码优化、硬件配置以及系统软件升级带来方便。即使经费有限的开发组织也可以对它们的网站进行负载测试，因为Microsoft的WAS是可以免费下载的。WAS要求WindowsNT4.0SP4或者更高，或者Windows2000。为了对网站进行负载测试，WAS可以通过一台或者多台客户机模拟大量用户的活动。WAS支持身份验证、加密和Cookies，也能够模拟各种浏览器类型和Modem速度，它的功能和性能可以与数万美元的产品相媲美。如果你对WAS和Microsoft的另外一个测试工具WebCapacityAnalysisTool（WCAT）之间的差别感兴趣，可以访问MicrosoftWeb工具的比较页面。

要对网站进行负载测试首先必须创建WAS脚本模拟用户活动。我们可以用下面四种方法之一创建脚本：通过记录浏览器的活动；通过导入IIS日志；通过把WAS指向Web网站的内容；或者手工制作。图1所显示的是通过记录浏览器事件生成的脚本的一部分，网站是Microsoft的DuwamishBookStore。Duwamish是Microsoft开发的电子商务Web应用示例，从Duwamish网站的“Phase4”链接可以下载这个软件包。下载包中包含了它自己的WAS测试脚本。

【图1】

制作WAS脚本是相当简单的，不过要制作出模拟真实用户活动的脚本有点儿复杂。如果你已经有一个运行的Web网站，可以使用Web服务器的日志来确定Web网站上的用户点击分布。如果你的应用还没有开始运行，那么只好根据经验作一些猜测了。

图1这个脚本中我们假定有30个会员在浏览书店，同时又有一个会员正在购买。要模拟两者混合而成的行为，首先必须创建页面组并在脚本的PageGroup分枝确定点击分布情况。在PageGroup分枝中我们可以增加、修改或删除页面组，也可以为各个组修改流量的分布。

图2显示了grp_browse和grp_buy这两个页面组以及30比1的流量分布

【图2】

创建了页面组之后，我们就可以在主脚本视图中赋予各个请求不同的页面组，如图3所示。为每个请求指定页面组相当于告诉WAS如何分布流量。记住在本例中对grp_buy组页面的请求约占总数的3%，而对grp_browse组页面的请求约占97%。

【图3】

如果需要在查询字符串中传递“名字-值”对，可以用WAS的查询字符串编辑器来定义各个变量的所有可能的值。在输入变量值后，既可以要求WAS顺序地使用变量的各个值，也可以要求WAS在请求时随机选择变量值。这在一定程度上增加了脚本所模拟行为的真实性，也可以帮助避免缓冲对测试结果的影响准备好测试脚本之后，我们可以调整测试配置以便观察不同条件下的应用性能。图4是WAS的设置界面

【图4】

StressLevel和Stressmultiplier这二个项决定了访问服务器的并发连接的数量。Microsoft建议不要选择超过100的StressLevel值。如果要模拟的并发连接数量超过100个，可以调整Stressmultiplier或使用多个客户机。在负载测试期间WAS将通过DCOM与其他客户机协调。有关在测试中使用多个客户机的更多信息，参见/kb/hkb13.htm。

如果网站提供个性化服务，要进行身份验证或使用Cookies，我们还要为WAS提供一个用户目录。WAS中的用户存储了发送给服务器的密码以及服务器发送给客户端的Cookies。增加用户数量并不增加Web服务器的负载。必须提供足够数量的用户以满足并发连接的要求（StesssLevel乘以StressMultiplier）。有关线程、用户、Cookies相互作用的更多信息请参见/Threads/WASThreads.htm。本文来自无涯教程网:

WAS允许设置warmup（热身）时间，一般可以设置为1分钟。在warmup期间WAS开始执行脚本，但不收集统计数据。warmup时间给MTS、数据库以及磁盘缓冲等一个机会来做准备工作。如果在warmup时间内收集统计数据，这些操作的开销将影响性能测试结果。

设置页面提供的另外一个有用的功能是限制带宽（throttlebandwidth）。带宽限制功能能够为测试模拟出Modem（14.kK，28.8K，56K）、ISDN（64K，128K）以及T1（1.54M）的速度。使用带宽限制功能可以精确地预测出客户通过拨号网络或其他外部连接访问Web服务器所感受的性能。

要理解这些不同的设置对应用的影响，有必要了解如何使用WAS收集性能数据。

使用WAS，从远程WindowsNT和Windows2000机器获取和分析性能计数器（PerformanceCounter）是很方便的。加入计数器要用到图5所示的PerfCounters分枝。

【图5】

在测试中选择哪些计数器显然跟测试目的有关。虽然下面这个清单不可能精确地隔离出性能瓶颈所在，但对一般的Web服务器性能测试来说却是一个好的开始。

·处理器：CPU使用百分比（%CPUUtilization）

·线程：每秒的上下文切换次数（ContextSwitchesPerSecond(Total)）

·ASP：每秒请求数量（RequestsPerSecond）

·ASP：请求执行时间（RequestExecutionTime）

·ASP：请求等待时间（RequestWaitTime）

·ASP：置入队列的请求数量（RequestsQueued）

CPU使用百分比反映了处理器开销。CPU使用百分比持续地超过75%是性能瓶颈在于处理器的一个明显的迹象。每秒上下文切换次数指示了处理器的工作效率。如果处理器陷于每秒数千次的上下文切换，说明它忙于切换线程而不是处理ASP脚本。

每秒的ASP请求数量、执行时间以及等待时间在各种测试情形下都是非常重要的监测项目。每秒的请求数量告诉我们每秒内服务器成功处理的ASP请求数量。执行时间和等待时间之和显示了反应时间，这是服务器用处理好的页面作应答所需要的时间。

我们可以绘出随着测试中并发用户数量的增加每秒请求数量和反应时间的变化图。增加并发用户数量时每秒请求数量也会增加。然而，我们最终会达到这样一个点，此时并发用户数量开始“压倒”服务器。如果继续增加并发用户数量，每秒请求数量开始下降，而反应时间则会增加。要搞清楚硬件和软件的能力，找出这个并发用户数量开始“压倒”服务器的临界点非常重要。

置入队列的ASP请求数量也是一个重要的指标。如果在测试中这个数量有波动，某个COM对象所接收到的请求数量超过了它的处理能力。这可能是因为在应用的中间层使用了一个低效率的组件，或者在ASP会话对象中存储了一个单线程的单元组件。

运行WAS的客户机CPU使用率也有必要监视。如果这些机器上的CPU使用率持续地超过75%，说明客户机没有足够的资源来正确地运行测试，此时应该认为测试结果不可信。在这种情况下，测试客户机的数量必须增加，或者减小测试的StressLevel。本文来自无涯教程网:

每次测试运运行结束束后WAAS会生生成详细细的报表表，即使使测试被被提前停停止也一一样。WWAS报报表可以以从Viiew菜菜单选择择Repportts查看看。下面面介绍一一下报表表中几个个重要的的部分。

如如果这是是一个新新创建的的测试脚脚本，你你应该检检查一下下报表的的RessulttCoodess部分。这这部分内内容包含含了请求求结果代代码、说说明以及及服务器器返回的的结果代代码的数数量。如如果这里里出现了了4044代码（页页面没有有找到），说说明在脚脚本中有有错误的的页面请请求。

页面摘摘要部分分提供了了页面的的名字，接接收到第第一个字字节的平平均时间间（TTTFB），接接收到最最后一个个字节的的平均时时间（TTTLBB），以以及测试试脚本中中各个页页面的命命中次数。TTTFBB和TTTLB这这两个值值对于计计算客户户端所看看到的服服务器性性能具有有重要意意义。TTTFBB反映了了从发出出页面请请求到接接收到应应答数据据第一个个字节的的时间总总和（以以毫秒秒计），TTTLBB包含了了TTFFB，它它是客户户机接收收到页面面最后一一个字节节所需要要的累计计时间。

报报表中还还包含了了所有性性能计数数器的信信息。这这些数据据显示了了运行时时各个项项目的测测量值，同同时还提提供了最最大值、最最小值、平平均值等等。报表表实际提提供的信信息远远远超过了了我们这这里能够够介绍的的内容。为为了给你你一个有有关表所所提供信信息种类类的印象象，图66摘录了了一个报报表实例例。

【图图6】

随着IInteerneet应用用的日益益广泛，用用户的要要求和期期望也在在不断地地发展。今今天的客客户期待待个性化化的可定定制的方方案，期期待这些些方案不不仅简单单，而且且快速、可可靠、成成本低低廉。对对于能够够适应用用户需求求不断变变动的可可定制页页面来说说，静态态HTMML已经经退出了了舞台，比比如内容容根据客客户请求求变化的的页面就就是其中中一例。这这一切都都要求系系统保存相关关的数据据，例如如有关用用户本身身以及用用户可能能请求哪哪些信息息的数据据。

紧跟跟这些趋趋势的WWeb开开发者已已经开始始提供可可定制的的Webb网站。象象搜索数数据之类类的任务务现在可可以由服服务器执执行而无无需客户户干预。然然而，这这些变革革也导致致了一个个结果，这这就是许许多网站站都在使使用大量量的未经经优化的的数据库库调用，从从而使得得应用性性能大打打折扣。

我我们可以以使用以以下几种种方法来来解决这这些问题题：

1.优化AASP代代码。

2..优化化数据库库调用。

3..使用用存储过过程。

4..调整整服务器器性能。

优优秀的网网站设计计都会关关注这些些问题。然然而，与与静态页页面的速速度相比比，任何何数据库库调用都都会显著著地影响响Webb网站的的响应速速度，这这主要是是因为在在发送页页面之前前必须单单独地为为每个访访问网站站的用户户进行数数据库调调用。

这这里提出出的性能能优化方方案正是是基于以以下事实实：访问问静态HHTMLL页面要要比访问问那些内内容依赖赖于数据据库调用用的页面面要快。它它的基本本思想是是：在用用户访问问页面之之前，预预先从从数据库库提取信信息写入入存储在在服务器器上的静静态HTTML页页面。为为了保证证这些静静态页面面能够及及时地反反映不断断变化的的数据库库数据，必必须有一一个调度度程序管管理静态态页面的的生成成。

当然然，这种种方案并并不能够够适应所所有的情情形。例例如，如如果是从从持续变变化的大大容量数数据库提提取少量量信息，这这种方案案是不合合适的。不不过可以以适用该该方案的的场合还还是很多多。

为为了保证证能够在在合适的的时间更更新静态态HTMML页面面，把下下面的代代码加入入到相应应的ASSP页面面前面：：

随着着Intternnet应应用的日日益广泛泛，用户户的要求求和期望望也在不不断地发发展。今今天的客客户期待待个性化化的可定定制的方方案，期期待这些些方案不不仅简单单，而且且快速、可可靠、成成本低低廉。对对于能够够适应用用户需求求不断变变动的可可定制页页面来说说，静态态HTMML已经经退出了了舞台，比比如内容容根据客客户请求求变化的的页面就就是其中中一例。这这一切都都要求系系统保存存相关关的数据据，例如如有关用用户本身身以及用用户可能能请求哪哪些信息息的数据据。

紧跟跟这些趋趋势的WWeb开开发者已已经开始始提供可可定制的的Webb网站。象象搜索数数据之类类的任务务现在可可以由服服务器执执行而无无需客户户干预。然然而，这这些变革革也导致致了一个个结果，这这就是许许多网站站都在使使用大量量的未经经优化的的数据库库调用，从从而使得得应用性性能大打打折扣。本文来自无无涯教程程网:hhttpp:///wwww.wuuyappc.ccom

我们可可以使用用以下几几种方法法来解决决这些问问题：

1..优化化ASPP代码。

2..优化化数据库库调用。

3..使用用存储过过程。

4..调整整服务器器性能。

优优秀的网网站设计计都会关关注这些些问题。然然而，与与静态页页面的速速度相比比，任何何数据库库调用都都会显著著地影响响Webb网站的的响应速速度，这这主要是是因为在在发送页页面之前前必须单单独地为为每个访访问网站站的用户户进行数数据库调调用。

这里提提出的性性能优化化方案正正是基于于以下事事实：访访问静态态HTMML页面面要比访访问那些些内容依依赖于数数据库调调用的页页面要快快。它的的基本思思想是：：在用户户访问页页面之前前，预先从数数据库提提取信息息写入存存储在服服务器上上的静态态HTMML页面面。为了了保证这这些静态态页面能能够及时时地反映映不断变变化的数数据库数数据，必必须有一一个调度度程序管管理静态态页面的的生成成。

当然然，这种种方案并并不能够够适应所所有的情情形。例例如，如如果是从从持续变变化的大大容量数数据库提提取少量量信息，这这种方案案是不合合适的。不不过可以以适用该该方案的的场合还还是很多多。

为为了保证证能够在在合适的的时间更更新静态态HTMML页面面，把下下面的代代码加入入到相应应的ASSP页面面前面：：

每当当该页面面被调用用，脚本本就会提提取最后后的更新新时间并并将它与与当前时时间比较较。如果果两个时时间之间间的差值值大于预预定的数数值，UUpdaate..aspp脚本就就会运行行；否则则，该AASP页页面把余余下的HHTMLL代码发发送给浏浏览器。

最最后更新新时间从从Apppliccatiion变变量得到到，它的的第一次次初始化化由gllobaal.aasa完完成。具具体的更更新时间间间隔应应根据页页面内容容的更新新要求调调整。

如如果每次次访问AASP页页面的时时候都要要提供最最新的信信息，或或者输出出与用户户输入密密切相关关，这种种方法并并不实用用，但这这种方法法可以适适应以固固定的时时间间隔隔更新信信息的场场合。

如如果数据据库内容容由客户户通过适适当的AASP页页面更新新，要确确保静态态页面也也能够自自动反映映数据的的变化，我我们可以以在ASSP页面面中调用用Upddatee脚本。这这样，每每当数据据库内容容改变时时服务器器上也有有了最新新的静态态HTMML页面面。

另另一种处处理频繁繁变动数数据的办办法是借借助MiicroosfttSQQLSServver7.00的Weeb助手手向导（WWebAsssisttanttWiizarrd），这这个向导导能够利利用Trranssactt-SQQL、存存储过程程等从SSQLSerrverr数据生生成标准准的HTTML文文件。

利利用SQQLSServver任任务，WWeb助助手向导导能够用用来定期期地生成成HTMML页面面。正如如前面概概要介绍绍的方案案，WWeb助助手可以以通过触触发子更更新HTTML页页面，比比如在指指定的时时间执行行更新或或者在数数据库数数据变化化时执行行更新。本文来来自无涯涯教程网网:htttp:://wwww..wuyyapcc.coom

SQLLSeerveer使用用名为ssp_mmakeewebbtassk的存存储过程程创建HHTMLL页面，它它的参数数是目标标HTMML文件件的名字字和待执执行存储储过程的的名字，查查询的输输出发送到HHTMLL页面。另另外，也也可以选选择使用用可供结结果数据据插入的的模板文文件。从前面面的代码码可以看看出，当当ASPP页面HHtmllMaiin.aasp需需要更新新时，控控制以AASP文文件的物物理路径径为参数数转到了了Upddatee页面。UUpdaate脚脚本的任务是是用新的的HTMML数据据刷新发发出调用用的ASSP文件件，并把把调度AASP代代码加入入到文件件的开头头。为此此，Uppdatte脚本本打开调调度模板板文件，拷拷贝调度度ASPP代码码，然后后控制转转到了另另一部分分脚本，这这部分脚脚本主要要任务是是执行数数据库操操作。UUpdaate用用路径参参数以写写模式打打开HttmlMMainn.assp文件件，数据据库操作作的输输出以HHTMLL格式写写入这个个文件。

万万一用户户访问页页面的时时候正好好在执行行更新，我我们可以以利用锁锁或者其其他类似似的机制制把页面面延迟几几秒钟。HtmmlMaain..aspp（纯HHTMLL加调度度ASPP代码）和和maiin.aasp（普普通的AASP文文件）在在WASS下进行行了性能能测试。mmainn.assp文件件要查找找5个个不同的的表为页页面提取取数据。为为了和这这两个文文件相比比较，一一个只访访问单个个表的AASP页页面（SSinggleTTablleTeest..aspp）和一一个纯HHTMLL文件（PllainnHtmml.hhtmll）也进进行了测测试。测试结结果如下下表所示示：文件名字命中数平均TTFFB（mms）平均TTLLB（mms）PlainnHtmml.hhtmll847474SinglleTaableeTesst.aasp868.888789.338Main..aspp9125.8893759..56HtmlMMainn.assp9149.8891739..89

其中TTTFBB是指TTotaalTTimeetooFiirsttByyte，TTTLBB是指TTotaalTTimeetooLaastBytte。

这些测测试在一一台WiindoowsNTWorrksttatiion4.00SPP6运运行PeersoonallWeebSServver的的机器上上实施。为为了使性性能指标标更明显显，带宽宽限制到到了144.4K。在在实际环环境中数数值变化化可能很很大，但但这个结结果精确确地