当DiscuzNT遇上了Loadrunner(中)
在上文中，介绍了如果录制脚本和设置脚本执行次数。如果经过调试脚本能够正常工作的话，就可以设置并发用户数并进行压力测试了。
首先我们通过脚本编辑界面上的“工具”菜单项，选择该菜单的第二项“Create Controller Scenario(创建控制场景)”，如下图：
这时，lr会弹出一个窗口，我们只要在select scenario type项中的number of vusers设置成1000，这样我们就可以用1000并发用户来测试我们上文中所执行的操作了，如下图：
注:之前在上文中设置脚本执行次数为5，这里又做了1000的并发用户，所以最终我们要创建的“主题数”等于：1000*5 = 5000，而这5000主题要在10分钟左右的时间里创建完成，压力不小，呵呵。
完成了这个设计并点击"ok”之后，我们就可以看到我们所设置的场被“创建”出来了，这里我们只要点击"start scenario”就可以启动压力测试了，如下图：
这里lr就可以运行压力测试了，同时我们可以从下图中看到正在测试过程中的各项参数，如下图（注意红字标注部分）：
从上图中的“并发用户”图中，答道可以看到，大经销商在5分钟时，并发用户数达到了1000的‘上限’，而在“响应时间”中我们看到“发主题”操作的执行 曲线在3分钟时创出响应时间的‘高峰’，且其执行时间普遍高于其它页面。而就在3分钟时并发用户数开始接近于1000，看来大并发对于发主题操作的压力不 小呀。其实在正常环境下，用户要求的响应时间维护在3-8秒左右，而像上图所posttopic_transaction中的“平均值”却达到了26秒 多，显然是不可接受的，但正如我在前一篇中所说的那样，这次测试是抱着一种将“服务器”压死的目的来测试的，所以设置的参数基本上已接近那台1u服务器所 能承受的上限了，当然这会上平均页面的响应时间变得‘过长’，但我认为正是这种‘慢动作’的‘假象’才能让系统处于‘疲于奔命’的情况，也才能让其问题能 够暴露的更全面一些。当然除了这种加大并发和工作量的方式之后，在lr中还可以通过设置‘集合点’的方式来制造更大的压力，只不过后者更倾向于对那些正在 改进或已改进的程序代码进行压力测试的情况，我会在后面优化程序的时候加以说明。
注：这里有必要介绍一下什么是“点击率（Hits/sec）”, 即每秒点击数，是在场景或会话步骤运行过程中VUser每秒向WEB服务器提交的HTTP请求数. 而上图中就是0--5分钟这段采样时间内VUser平均每秒发送的HTTP请求数。而这个值的图表‘走势’是与系统的‘吞吐量（Throughput）’ 相对应的，这一点会在生成测试报告时加以解释说明。
一般在这个时间，我会在到达1000并发用户（图中4分钟左右）时，习惯性的去看一下服务器的cpu，内存和网络情况，因为这时如果cpu处于长时间100%时就是已到了系统瓶颈了，下面就是此时服务器端的cpu，内存使用情况：
上图中，我们看到cpu经常在100%的使用率上徘徊，并且一旦到了100%的高峰上时，就会持续一段时间，大约为3-5秒，然后就会迅速下跌。这说明系 统在此时‘可能’出现了资源争用情况，比如内存，文件或数据库等，而此时图中内存使用情况并不高，可以排除内存方面的问题，还有就是此时的网络情况也并未 造成拥塞（如下图：经常处于20-50%的状态下），所以网络方面的因素也应该予以排除了。
那么就只剩下文件访问和数据库方面的问题了。因为在discuznt中使用了配置文件方式来设置系统参数，并且其文件被加载之后就被static方式进行声明，所以一旦系统运行起来之后，就不会频繁访问文件了，这一点在之前的“Discuz!NT之配置文件类”中已做过说明，所以最后就剩下数据库方面的因素了。
注：如果大家有人能搞到正版lisence的话，就不用这么麻烦了，因为lr会自动收集这方面的信息，可以在生成报造时给我们提供在测试周期内的cpu,内存，网络方面的详细结果，以便于我们在‘决策’时有准确的数据进行参考。而我本人这种做法只是权宜之计，且在准确性上也要打上‘折扣’。
如果一切正常的话，这个测试会在10分钟后运行完毕，这时我们就可以点击‘控制场景’中的工具条上的这个图标来生成测试报告了（终于到了采摘‘胜利果实’的时候了），如下图：
这样lr就会将刚才的测试过程生成一份报告，下面就来介绍一下这个报告（关于如何分析报告以及优化程序，因为内容较多，不可能在本文中详细介绍，只能在下一篇中说明了），如下图：
下面就是其报告首页的介绍（注意红框和说明）：
而在首页还有一个信息就是静态统计，如下图（红框部分）：
其中：
Maxinum Running Vusers:就是模拟的最大运行用户数(951)人，这里为什么不是1000，我想主要还是与测试过程中的服务运行状态和lr测试机本身的情况所决定的，这个值会随你不断反复测试而有所变化的。
Total Throughput(bytes):即吞吐总量，是在测试过程中场景执行时从Server上接收到的数据总量（以字节为单位，千万别看错单位，要不心脏不好的TX肯定会晕过去了，呵呵）。
Average Throughput(bytes/second):即每秒吞吐量，即在场景执行期间每秒从Server上接收到的数据量的值。这个值一般与网络带宽相比较，用以判断目前的网络带宽是否是瓶颈。
Total Hits:总点击率，在场景或会话步骤运行过程中VUser向WEB服务器提交的HTTP请求总数.
Average Hits per Second:每秒点击数，即在场景或会话步骤运行过程中VUser每秒向WEB服务器提交的HTTP请求数.
看了这些参数，其实我一般很少看它们，因为对于优化程序来说，多数时间是要看运行图形的变化情况，而不是这些统计值或平均数，它们只是告诉你系统的运行情况是好是坏，却不能告诉你系统的瓶颈出在了哪里。下面就来简单介绍一下报告中几个非常重要的图表，首先就是并发用户图：
该图显示的是并发用户数量在整个测试周期中的生成情况，可以看到在3分钟后，并发用户数到达了顶峰，并在6分钟后高峰退去。所以在这段时间内是个‘敏感期’，我们要特别重视在这个时间段内系统的反映情况。
接着就是每秒点击率图：
这个图看到在3--6分钟出现了三个高峰（值基本上到达了1300），而这个期间与上面的并发用户高峰时段正好‘稳合’，原因很好解释，必定用户多了，操作多了，自然向服务器提交的http请求就多了。
接下来，再看一下‘吞吐量’：
这一张图基本上已上前的点击率图的走势差不多，原因很好解释，因为操作请求多了，服务器端忙了，在服务端能正常处理请求的情况下，自然接收到的数据量相应也会增加了。
下面再介绍一下事务执行情况，这张图可以帮助我们看到那些action执行时出了问题（红色部分为出错），那些工作良好（绿色为良好）。
最后一个图就是我经常看的图了，“平均时间响应时间”，它告诉我们那个action的执行时间过长，那些基本稳定，那些先是稳定但大并发来时出了问题。
当然，除了这五个图表之后，lr还提供了更多其它方面的图表，比如页面大小，文件(js,css,aspx等)元素加载时间等，比如下图就是我经常添加的图表：
其中：
Web Page Breakdown：会告诉你所做的action中，每个页面（aspx,js,css,img）的加载时间（最大，最小，平均值）
Page Downloaded Time Breakdown: 页面下载时间，包括dns解析时间，首次缓冲时间，发起链接时间等。
Downloaded Component：每个页面体积尺寸，以便于分析那些页面体积过大，从而影响网络传输或处理速度。
最后声明一下，上面这些图只是说明各个图表的性质和作用，并不是优化前的最终测试结果。
在下一篇中，我们通过最终的测试数据来找出系统有那些瓶颈，以及如果优化数据库访问查询，更新等。
好了，今天的内容就先到这里了。
原文链接: http://www.cnblogs.com/daizhj/archive/2009/09/27/1574897.html
作者: daizhj, 代震军
Tags: loadrunner,压力测试,discuznt