使用WAS对Web应用程序进行压力测试

msnshow

5.8 Page Data

显示了各个请求内容的更加详细的信息。技术需求中的运行效率信息可以在这里验证。

25%、50%、75%的数字还没有弄明白什么意思？？？？？平均值还不知道怎样计算出来的

6 其他方式编写测试脚本

在前边提到，编写测试脚本有4种方法，现在对其他三种方法进行简单的介绍

6.1 手动编写测试脚本

打开菜单，选择Scripts|Create|Manual
手动创建一个测试脚本

msnshow

然后出现了NewScript，[server]中输入要进行测试的服务器IP地址或计算机名称；在脚本的内容表格中[verb]项选择脚本运行方式 get、post、head；[path]中输入向服务器提交的文件或字符串。

msnshow

6.2 导入IIS日志

这种方法适合于开始投入运行的Web应用程序。IIS日志记录了用户访问系统的所有信息。通过导入IIS日志的方法建立的测试脚本，是最符合实际运行情况的方法。如果有IIS日志，我们推荐使用这种方法。

这种方法也比较简单。打开菜单，选择Scripts|Create|Log 导入IISs日志创建一个测试脚本。

msnshow

然后出现导入IIS日志的第一步，选择IIS日志的路径，默认情况下的路径如图所示

msnshow

Next进入第二步，一般情况下不用做改动。取默认即可

Finish后，WAS自动生成脚本。6.3 导入网站内容文件
这种方法通过导入网站上具体的文件来生成测试脚本。一般情况下，不推荐使用这种方法。下面简单说明这种方法的使用。打开菜单，选择Scripts|Create|Contents ，WAS自动新建一个测试脚本，并且切换到Contents Tree节点。

msnshow

然后回到New Script的主页面，会看到选择的内容文件自动添加到表格中

msnshow

使用方法就是这样。

7 初步的想法

1 在大规模的测试时，需要很多WAS客户端。为了充分利用资源，可以在项目组每个人的机器上都安装WAS软件（只要正确安装，启动WebTool服务即可）。这样测试时，WAS会自动协调，自动分配线程。

2 我们的系统中有很多的角色。虽然WAS可以将不同角色执行请求的顺序进行混合，但是这样我们不知道WAS怎样混合的，不能随时控制角色的状态。建议将不同的角色分组，每个角色放到一个WAS测试机（充当控制器）上，这样可以分角色而又集中的对WebServer进行压力测试，同时又能随意的控制各个WAS客户机的状态。这种思想是模仿LoadRunner软件，具体实施还需要不断的实验和学习。

3 在集成测试时，先注重性能方面的测试，逐步的加压，寻找WebServer的最大负载量。进而对照技术需求，不断改进。

4 WAS首先是性能测试工具，然后才是压力测试工具。具体测试时，可以先在正常的条件下（满足技术需求）进行性能测试，然后才是异常情况（增加压力到技术需求规定的1.5-2倍）的测试。

5 不断的研究学习，利用WAS更深入地了解你的应用的性能、稳定性、瓶颈和局限性。

msnshow

8 存在的问题

目前存在的问题：

   1 在测试结果Report中的Page Data部分，25%、50%、75%的值到底是什么意思？Average又是怎样计算出来的

   2 在关于身份验证的页面中，如何模拟多用户使用不同的账号登陆？按照帮助说明和例子的说明，在ASP.NET开发的登陆程序中没有试验成功。（帮助中这么说明：取用户名是在POST数据项中把用户名用“%Username%”代替，密码用“%Password%”代替）

3 添加性能计数器时，添加本机的当然没有问题。但是如何添加服务器的性能计数器。这需要在服务器端进行设置，但怎样设置？还没有弄清楚。（这个问题已经清楚了，服务器端不需要任何设置，只要客户机和服务器在一个工作组即可）

msnshow

9 性能优化

   以下文字摘自网络上的文章。仅供参考。

随着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代码发送给浏览器。

msnshow

最后更新时间从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个用户获得了好处。

　　静态页面方法并不能够适合所有类型的页面。例如，某些页面在进行任何处理之前必须要有用户输入。但是，这种方法可以成功地应用到那些不依赖用户输入却进行大量数据库调用的页面，而且这种情况下它将发挥出更大的效率。

　　在大多数情况下，动态页面的生成将在相当大的程度上提高网站的性能而且无需在功能上有所折衷。虽然有许多大的网站采用了这个策略来改善性能，也有许多网站完全由于进行大量没有必要的数据库调用而表现出很差的性能。

天下无双1

一个不错的工具

hbxtly

很小巧的工具，最初用过