性能测试实践——快速定位及缩小范围

发表于:2017-8-31 12:59  作者:学性能的小宋   来源:51Testing软件测试网采编

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 性能测试 软件测试技术

  性能测试是工程级的工作对象,因此要关注的点比较多,相信每个做性能测试的同学都有自己的思路和习惯,我来分享一下自己的心得。
  一、性能测试监控思路
  (1)首先是判断是否出现性能瓶颈,结合部署架构猜测瓶颈出现哪一段。
  (2)查看日志、使用监控工具或者其他方式来印证你的猜测。
  (3)查看操作系统的参数,通过多方数据确认,证明现象的合理性。
  (4)系统调优,再次测试确定调优效果。
  二、说了那么多,找个实例来看。
  先部署环境画个部署架构
  典型的三层结构:web层是nginx+tomcat(放的是api的包);mt层的nginx+tomcat(就是rpc或者服务治理的包,dao方法都在mt层的tomcat里)
  (1)发现瓶颈:
  省去中间的程序直接压测,发现并发量20的时候响应时间是100ms,并发量30的时候响应时间是150ms。
  tps不变了,出现了系统瓶颈。
  (2)查看系统参数,缩小范围。
  <1>系统瓶颈一般就是网络、操作系统、中间件、技术架构、应用、io等。首先看下sar -A过一下基本参数,看看有什么异常。
  ——结果发现是没有什么异常,所以怀疑到前端的网络和中间件,比如mycat。
  <2>看代码了解到我的方法是web层一个api的service调用了2个mt层的service(mt层用到了2个dao的4个sql),所以我倾向于mycat+mysql这段存在瓶颈。但是操作系统没有io瓶颈,这就尴尬了,那我把3个服务都打个消耗时间的日志看看。
  ——打印结果发现请求的消耗时间确实在web层的api和mt层的一个dao里面。这样就能排除掉网络、nginx的问题(或者说从发请求到tomcat的这个过程是没有问题的)
  <3>既然已经快速的缩小范围了,问题就比较好排查了,理应怀疑sql执行效率,但是别忘了系统io执行效率并不高,那我就认为dao的代码写的有问题。
  (3)分析问题,证明操作系统的数据合理性
  其实定位到这个范围基本已经能猜到一些可能性了:数据库连接数、tomcat连接数、dao层是否有一些等待逻辑、锁等待、包括容器的内存是不是溢出了,我们现在先不扩展。
  我把dao的问题叫开发定位了一下,反馈给我说有2个sql在业务上就不需要,另外发现多次调用dao的逻辑,那么就定位到数据库的连接数了。
  ——印证了系统的监控现象,io利用率低。
  (4)在下一个版本再次回归。
  补充点知识:一个请求的消耗时间是多个节点(网络、系统、nginx、tomcat...)的消耗时间之和,所以我们的定位思路就要分段拆分、判断缩小瓶颈的发生范围。
  打印日志也是有技巧的,我会在报文里传入一个id作为整个会话的标识,并且把这个id传入到他的子服务中去,这样就能精确算出每个方法的消耗时间。
  总结:性能测试主要目标就是快速定位到工程级的问题并解决回归的过程。用什么方法、工具都不重要。
  说个题外话随着各种技术和框架的发展,以及各种监控工具的完善,性能测试这个行为变得越来越简单和容易,假设我使用pinpoint监控可以实时看到每个方法的消耗时间,可能上述的1~3步可以秒定位到,那么借助工具提升工作效率,同时印证自己的思路是好事。
  (我们经常开玩笑说性能测试可以申遗了,境遇很像传统手工业)
  但是基础薄弱的同学,我建议还是少依赖工具,不要迷失于工具的使用者这个层面了,而且由于不了解原理你会遇到很多问题没办法解决。所以我们的定位是问题的终结者,而不是发现者。

>>每天充电一小时,搞定Python全栈测试开发

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2019, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道