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：每个页面体积尺寸，以便于分析那些页面体积过大，从而影响网络传输或处理速度。

 

      最后声明一下，上面这些图只是说明各个图表的性质和作用，并不是优化前的最终测试结果。

 

      在下一篇中，我们通过最终的测试数据来找出系统有那些瓶颈，以及如果优化数据库访问查询，更新等。

 

      好了，今天的内容就先到这里了。