当DiscuzNT遇上了Loadrunner(下)

简介:
  在之前的两篇文章中,基本上介绍了如何录制脚本和生成并发用户,同时还对测试报告中的几个图表做了简单的说明。今天这篇文章做为这个系列的最后一篇,将会介绍如何通过测试报告来查看系统的运行情况,找出影响性能的因素,以及如何去进行优化。
       首先,看一下这张并发用户的图:
        lr_before_1_user
      这是在优化之前我生成的测试报告的截图,通过这张图可以看到这个测试过程长达24分钟(这在之前的无数次测试中算是具有代表性的了),
而并发用户峰值是从4--15分钟,持续时间近11分钟。就目前而言,其执行的测试时间和高峰持续时间肯定要比discuz(php)要差了不少,因为dz那边基本上也就是10多分钟就‘完活’了。这里先把这张图放一放,看一下平均事物响应时间这张图, 如下:
      lr_before_4_posttopic   
 
 
 
       可以看出目前最耗时的操作就是“发主题(posttopic)”了,我们通过在该图上点击鼠标右键,然后选中merge graphs来进行图表合并,这里将并发用户(上图)与本图进行合并:
      lr_before_5_posttopic_merge
       合并之后的图如下,:
lr_before_5_posttopic_merge2
       首先可以肯定的是在并发上来时(1000用户,posttopic基本上处于最高位,同时查看主题(showtopic),显示版块(showforum)也有‘走高趋势’)。直到并发过去了之后,用户数下来了,这几个操作的响应时间才又快了起来。其实到这里,我认为可以将posttopic作为优化起点,然后依次是showtopic,showforum事务。注意我这里用的是‘事务’而不是页面,原因很简单,比如posttopic事务内部包括:发主题和跳转到showtopic页面这两个操作(回想一下我在第一篇中的说明)。为了看的更‘清楚’,这里有必要加入几张图,如下:
lr_addchart
   
 
 
 
       然后点击“opengraph”按钮,加入这四个图,这时我们将web page breakdown打开并定到posttopic_transaction,看一下这个事务中相应
操作的执行情况,如下:
lr_before_7_posttopic_ajax
       首先一个‘发现’,就是这个页面串不仅仅有之前所说的“发主题”,“显示主题”,还包括另一个 ajax请求,且其耗时达到15秒,而这是之前没有想到的,按说不应该在这个事务中出现。换句话说, 发主题事务给ajax加载背了‘黑锅’(注:后来经过测试发现,这个请求是在页面加载时就发出了,而原本可以在用户鼠标点击之后再加载),如下:
        lr_smilies   
      接着再看一下发主题成功之后,跳转回“显示主题页面”(showtopic)的操作情况:
lr_before_8_posttopic_jump
 
      而下面是posttopic,提交post请求时的处理时间(19秒,虽目前可以接受,但估化之后,这个时间被大幅提升):
     lr_before_9_posttopic_single 
 
 
 
     看来光就提交而言,posttopic还是比showtopic快,看来之前的优化顺序要做一下调整,将posttopic与showtopic这两个页面放在同一优先级上进行优化了。下面接着再看一下showtopic这个transaction的执行情况,如下图:
     lr_before_10_showtopic_ajax
    
       一看吓一跳,怎么这个页面里也有那个ajax加载呀,看来问题不那个简单了,下面再看一下showtopic页面的加载时间:
    lr_before_11_showtopic_single
       
      看来这个ajax加载已经像狗皮膏药一样粘在我们产品身体上,赶紧把问题打给相关的开发者吧,呵呵。
 
      在完成了这些事务分析之后,还有一个问题,就是对吞吐量的观察,因为如果吞吐量(Throughput)的曲线随着Vuser数量的增加没有增加,而是呈现出比较平的直线,说明当前的网络速度不能够满足目前的系统的要求,网络造成了瓶颈。为了排除这种可能性,有必要看一下吞吐量这张图,如下:
lr_before_throughout
       图表显示还是正常的,松了口气(必定是100兆带宽呀)。下面就开始专门优化一下相应的页面和数据访问操作了。
       这里,我还是使用了的profiler来观察有那个sql操作被频繁执行,如下图:
      lr_profiler  
      注:这里为了简化篇幅,直接将最终的观察结果列了出来。
       首先是频繁的在线表操作更新,方法名称:OnlineUser.UpdateAction(…),经过优化,该操作在showforum,showtopic,posttopic页面中的调用次数 从两次变成了一次。
      接着是对获取用户信息的操作,方法名称:User.GetShortUserInfo(),方法因为在传参时使用了不当的参数,导致在更新用户积分时还需要被执行一到两次。
      更新用户积分:Users.UpdateUserCredit(), 这个操作主要用在了posttopic页面中,因为其原来的设计时传参无法做到通用,导致后续开发者不得不再写一个效率不高的方法来满足自己的需要,影响了提交主题页面的执行效率。
      当然除了上述三个主要问题外,还有一些别的问题,这里就不一一列举了。当然这些问题都通过重构优化加以解决了(包括之前的ajax请求问题)。所以最终我们看到的优化之后的结果如下(注:为便于对比,我将优化前和优化后的截图一起发上来):
     首先是 优化前
lr_bad_2
      优化后:
lr_nomarl_2
      可以看出主要的页面性能都被提升上来了,特别是posttopic 这个事务,从65提到了26。这里要特别说明的是,在写本文之前,我们还在持续优化程序性能, 所以说“ 面对优化,只有起点,没有终点”。
     下面是优化前和优化后的1000并发cpu使用率的截图:
     lr_discuznt_cpu_bad2
    优化后的cpu使用率:
    lr_discuznt_cpu_2 
 
  同时,这里再附上一张对discuz进行压力测试时其在1000并发用户时的cpu运行截图:
lr_discuz_cpu
  而discuz的测试报告截图如下:
lr_discuz_report
 
      好了,基本上的流程就介绍完了,下面介绍个小插曲,以免让别人犯跟我一样的错误。
      在前一轮优化中,因为我们的产品有 弹窗发主题非弹窗发主题两个设置,而就在对非弹窗发主题时出了岔子,导致我在这个功能测试上花一近1天的时间找原因,如下图:
    lr_before_12_nightmare
 
     当然因为我们的这个功能用的是一个页面,即posttopic, 而在这个页面的cs中,“非弹窗下”使用了这个方法:SetMetaRefresh(5)
     其作用就是在发主题成功后,先不跳转到showtopic页面,而是暂停在本页上5秒中(来显示‘ 提交成功’这类的信息字样,如下图):
                 posttopic_result
      然后再用meta元素跳转到showtopic,而就是这5秒,人为的降低了页面的响应时间,而lr就真‘诚实’地将这5秒也照单记录了下来,导致在这个事务上响应时间高的吓人。而discuz在后台有相应的开关来控制是否显示‘提交成功’。当然现在我们已在后台加入了类似的设置。
      另外还有一点就是,通过优化一些重要的页面,还可能带来其它页面执行效率上的提升, 必定难做的工作做快了,系统就能腾出手来加快其它工作的执行速度了,呵呵。
      其实在lr中,这类东西只是冰山一角,只要你有lisence,你能看到的东西会更多,比如你可以看到 cpu上下文切换对系统吞吐量的影响,如下图:
       lr_cpu_cotext
      还有如果进行 数据库压力测试设置集合点参数化等很多有用的功能。
      好了,今天的内容就先到这里了,继续优化程序去:)
 


本文转自 daizhenjun 51CTO博客,原文链接:http://blog.51cto.com/daizhj/216792,如需转载请自行联系原作者
相关文章
|
搜索推荐
分享5款轻量级的Win10神器,错过你会后悔的
今天我要为大家推荐五款小众而且小体积的WIN10小工具,它们可以让你的电脑使用更加方便和高效,而且不占用太多的空间和资源,非常适合轻量级的办公和娱乐。
139 1
|
存储 消息中间件 安全
「避坑宝典」为大家分享一下笔者在 2022 年所遇到“匪夷所思”的 Bug 趣事(上)
「避坑宝典」为大家分享一下笔者在 2022 年所遇到“匪夷所思”的 Bug 趣事(上)
82 0
|
前端开发 网络协议 jenkins
三分钟,我让搞后端的学弟爱上了Eolink
突然某一天,一个特别能卷的学弟向我请教接口工具……
三分钟,我让搞后端的学弟爱上了Eolink
|
设计模式 监控 Java
简直人生外挂,直接涨薪25K,跪谢这份Java性能调优实战宝典
从整个软件生命周期的视角去关注与审视软件性能,通过主动式地设计与实现来主导软件性能,这样才能保证软件性能长期保持竞争力。针对这些问题,我结合自己十余年的性能调优开发经验。
|
监控 前端开发
摸鱼搞了个掘金数据监控桌面应用,还不快用起来!
`小f`搞了个Electron桌面应用的开源项目,最近在找人给他提`PR`,然而我前天半夜摸鱼,正好逛github逛到他仓库了,突然发现,欸,好像可以嵌进去一个`掘金数据监控`的插件,于是,在我的不懈(~~努力~~)摸鱼下,它完成了~
|
监控 前端开发 jenkins
我用这一招让团队的开发效率提升了 100%!
我在一家做微信营销的公司干技术 leader,带 40 多个人,公司名就不说了。在这个位置上做了好几年,把团队从小带大,公司虽然不算风口浪尖上的高增长业务,但技术这块儿也从来没出过什么问题,我还是蛮自豪的。
|
C# 数据安全/隐私保护 内存技术