当DiscuzNT遇上了Loadrunner(中)

简介:
在上文中,介绍了如果录制脚本和设置脚本执行次数。如果经过调试脚本能够正常工作的话,就可以设置并发用户数并进行压力测试了。
       首先我们通过脚本编辑界面上的“工具”菜单项,选择该菜单的第二项“Create Controller Scenario(创建控制场景)”,如下图:
 
     loadrunner_rec_15
 
      这时,lr会弹出一个窗口,我们只要在select scenario type项中的number of vusers设置成1000,这样我们就可以用1000并发用户来测试我们上文中所执行的操作了,如下图:
     loadrunner_rec_16
 
      注:之前在上文中设置脚本执行次数为5,这里又做了1000的并发用户,所以最终我们要创建的“主题数”等于:1000*5 = 5000,而这5000主题要在10分钟左右的时间里创建完成,压力不小,呵呵。
 
      完成了这个设计并点击"ok”之后,我们就可以看到我们所设置的场被“创建”出来了,这里我们只要点击"start scenario”就可以启动压力测试了,如下图:
loadrunner_rec_17
 
      这里lr就可以运行压力测试了,同时我们可以从下图中看到正在测试过程中的各项参数,如下图(注意红字标注部分):
lr_normal

  如果一切正常的话,这个测试会在10分钟后运行完毕,这时我们就可以点击‘控制场景’中的工具条上的这个图标来生成测试报告了(终于到了采摘‘胜利果实’的时候了),如下图:
    lr_createreport
 
      这样lr就会将刚才的测试过程生成一份报告,下面就来介绍一下这个报告(关于如何分析报告以及优化程序,因为内容较多,不可能在本文中详细介绍,只能在下一篇中说明了),如下图:
lr_report_frame
 
      下面就是其报告首页的介绍(注意红框和说明):
        lr_report1
  
     而在首页还有一个信息就是静态统计,如下图(红框部分):
      lr_report
 
       其中:
         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请求数.
 
      看了这些参数,其实我一般很少看它们,因为对于优化程序来说,多数时间是要看运行图形的变化情况,而不是这些统计值或平均数,它们只是告诉你系统的运行情况是好是坏,却不能告诉你系统的瓶颈出在了哪里。下面就来简单介绍一下报告中几个非常重要的图表,首先就是 并发用户图
        lr_report2
       该图显示的是并发用户数量在整个测试周期中的生成情况,可以看到在3分钟后,并发用户数到达了顶峰,并在6分钟后高峰退去。所以在这段时间内是个‘敏感期’,我们要特别重视在这个时间段内系统的反映情况。
 
      接着就是 每秒点击率图:
lr_report3
      这个图看到在3--6分钟出现了三个高峰(值基本上到达了1300),而这个期间与上面的并发用户高峰时段正好‘稳合’,原因很好解释,必定用户多了,操作多了,自然向服务器提交的http请求就多了。
 
      接下来,再看一下‘吞吐量’:
lr_report44
 
        这一张图基本上已上前的点击率图的走势差不多,原因很好解释,因为操作请求多了,服务器端忙了,在服务端能正常处理请求的情况下,自然接收到的数据量相应也会增加了。
        下面再介绍一下事务执行情况,这张图可以帮助我们看到那些action执行时出了问题(红色部分为出错),那些工作良好(绿色为良好)。
lr_report4 
 
 
 
 
 
      最后一个图就是我经常看的图了,“平均时间响应时间”,它告诉我们那个action的执行时间过长,那些基本稳定,那些先是稳定但大并发来时出了问题。
lr_report5
 
        当然,除了这五个图表之后,lr还提供了更多其它方面的图表,比如页面大小,文件(js,css,aspx等)元素加载时间等,比如下图就是我经常添加的图表:
     lr_report6
 
    其中:
         Web Page Breakdown:会告诉你所做的action中,每个页面(aspx,js,css,img)的加载时间(最大,最小,平均值)
         Page Downloaded Time Breakdown: 页面下载时间,包括dns解析时间,首次缓冲时间,发起链接时间等。
         Downloaded Component:每个页面体积尺寸,以便于分析那些页面体积过大,从而影响网络传输或处理速度。
 
      最后声明一下,上面这些图只是说明各个图表的性质和作用, 并不是优化前的最终测试结果
 
      在下一篇中,我们通过最终的测试数据来找出系统有那些瓶颈,以及如果优化数据库访问查询,更新等。
 
      好了,今天的内容就先到这里了。


本文转自 daizhenjun 51CTO博客,原文链接:http://blog.51cto.com/daizhj/216786,如需转载请自行联系原作者
相关文章
|
9月前
|
Oracle Java 关系型数据库
神级程序员都在用什么工具?
神级程序员都在用什么工具?
|
存储 消息中间件 安全
「避坑宝典」为大家分享一下笔者在 2022 年所遇到“匪夷所思”的 Bug 趣事(上)
「避坑宝典」为大家分享一下笔者在 2022 年所遇到“匪夷所思”的 Bug 趣事(上)
80 0
|
前端开发 网络协议 jenkins
三分钟,我让搞后端的学弟爱上了Eolink
突然某一天,一个特别能卷的学弟向我请教接口工具……
三分钟,我让搞后端的学弟爱上了Eolink
|
JSON 前端开发 JavaScript
前端老司机 70+ 实用工具网站分享(建议收藏!)🔥🔥(下)
前言 大家好,我是HoMeTown,好的工具,可以帮助我们大幅提高编程效率,今天给大家分享一下我平时收集到的一些工具,目录已经分好了。
96 0
|
前端开发 JavaScript 算法
前端老司机 70+ 实用工具网站分享(建议收藏!)🔥🔥(上)
前言 大家好,我是HoMeTown,好的工具,可以帮助我们大幅提高编程效率,今天给大家分享一下我平时收集到的一些工具,目录已经分好了。
144 0
ADS2020安装陷阱你学废了吗,小白狂喜教程
ADS2020安装陷阱你学废了吗,小白狂喜教程
666 0
ADS2020安装陷阱你学废了吗,小白狂喜教程
|
监控 前端开发
摸鱼搞了个掘金数据监控桌面应用,还不快用起来!
`小f`搞了个Electron桌面应用的开源项目,最近在找人给他提`PR`,然而我前天半夜摸鱼,正好逛github逛到他仓库了,突然发现,欸,好像可以嵌进去一个`掘金数据监控`的插件,于是,在我的不懈(~~努力~~)摸鱼下,它完成了~
|
监控 Java 应用服务中间件
强烈推荐|你不可不知的性能优化内幕
一. 基本概念 1. 软件系统质量特性 安全性:同时兼顾向合法用户提供服务,以及阻止非授权使用软件及资源的能力。 健壮、可靠:软件系统在一定的时间内无故障运行的能力、容错能力、恢复能力 可扩展、可维护、可移植:正在运行的软件系统以适应新需求、变化了的需求的难易程度 可用性、易用性、性能:性能是指软件及时提供相应服务的能力。
1976 0
|
前端开发 测试技术 开发者