讲讲那些大家不知道的性能测试

发表于:2023-11-07 09:41

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:佚名    来源:知乎

分享:
  前言
  性能测试大致分以下几个步骤:
  1.需求分析
  2.脚本准备
  3.测试执行
  4.结果整理
  5.问题分析
  今天要说的是最后一个步骤——“问题分析”。
  需求描述
  有一个服务,启动时会加载一个1G的词表文件到内存,请求来了之后,会把请求词去词表里做模糊匹配,如果匹配到了就向一个后端服务发送一条http请求,拿回数据之后,返回给客户端的同时,向mysql记录请求的唯一标识和一个请求次数的标记; 
  其中有几个关键函数 :
  ·模糊匹配(fuzzyMatching) 
  · 后端请求函数(sendingRequest) 
  · 拼装请求函数(buildResponse) 
  · 记录mysql请求次数标记(signNum)
  问题及分析
  第一组:完全随机请求词,qps达到1k时,服务器未见异常,cpu、内存、带宽均未满,qps无法继续提升;
  分析:由于此服务后端连接了其它服务,所以在压测之前,要确认后端服务不会成为瓶颈点,目前的状态很可能是后端服务限制了被测服务的性能;此时可以检查后端服务所在机器的各项指标,或者查看本机的连接状况,一般后端服务无法处理,而被测服务又会一直向后面请求的话,timewait状态的连接会变得比较多;
  第二组:解决后端服务的问题后,第二组使用平均30个字的请求词,来打压,qps到400时,cpu load已满;
  分析:这种情况明显是由于fuzzyMatching函数计算效率的问题导致cpu满载,从而无法提升qps,使响应时间不断增大,此时可以通过perf+火焰图来确定整个处理请求过程中响应时间长的函数;此时需要评估压测数据是否合理,如果线上平均请求词只有2个的时候,此组测试明显不合理,此时要开发进行性能优化就是浪费时间的;如果评估测试数据合理,可以再次更换短词数据进行压测验证猜测;
  第三组:解决了上述两个问题之后,使用完全随机请求词,qps到达3k后降低至1k,然后再次提升到3k,如此反复;
  分析:此时关注一下各项指标,排除了以上的问题的话,操作mysql慢的问题可能性大一些,对这种需要高并发的系统来说,直接读写mysql不是个聪明的解决方案,一般会用redis做一层缓存,这里说道的另一个问题就是开发设计不合理,导致的性能问题; 
  第四组:将后端换做真实的服务来做整体压测,发现qps最高只能到300,此时检查各项指标,发现入口带宽占满了;
  分析:这次问题比较明显,后端服务返回内容过大,导致带宽被占满,此时依然需要评估需求:1、是否需要后端返回的所有数据内容;2、评估更换万兆网卡的性价比;3、是否可以通过技术手段优化带宽占用,比如把一次请求分散到多组服务的多个请求;
  perf+火焰图定位函数问题
  这里简单说一下如何使用perf+火焰图来直观的定位性能问题:
  perf
  Perf 拥有了众多的性能分析能力,举例来说,使用 Perf 可以计算每个时钟周期内的指令数,称为 IPC,IPC 偏低表明代码没有很好地利用 CPU。Perf 还可以对程序进行函数级别的采样,从而了解程序的性能瓶颈究竟在哪里等等。Perf 还可以替代 strace,可以添加动态内核 probe 点,还可以做 benchmark 衡量调度器的好坏。
  · 使用举例:perf record -e cpu-clock -g -p 11110 -o data/perf.data sleep 30
  · -g 选项是告诉perf record额外记录函数的调用关系 
    -e cpu-clock 指perf record监控的指标为cpu周期 
    -p 指定需要record的进程pid
  生成火焰图
  1、第一步 
  使用压力测试工具对程序进行打压,压到程序拐点; 
  $sudo perf record -e cpu-clock -g -p 11110 
  Ctrl+c结束执行后,在当前目录下会生成采样数据perf.data. 
  2、第二步 
  用perf script工具对perf.data进行解析 
  perf script -i perf.data &> perf.unfold 
  3、第三步 
  将perf.unfold中的符号进行折叠: 
  ./stackcollapse-perf.pl perf.unfold &> perf.folded 
  4、最后生成svg图: 
  ./flamegraph.pl perf.folded > perf.svg
  到这儿可以生成函数调用火焰图,如下图:
  原生的perf可以直接定位C/C++的程序,通常编译debug版本的程序能看到更多的信息,java、go等语言可以通过各自定制的工具来生成,原理类似;通过火焰图可以轻松定位到哪个函数的处理时间最长,从而找到问题所在;
  结尾
  本文YY了一个项目,YY了一些场景来分析一些真实的性能问题,平时的性能测试中遇到的问题远比文中列举的多,有代码逻辑问题、服务器配置问题、服务部署问题、甚至需求合理性的问题,每个问题都有自己分析定位的套路,掌握了这个套路就可以解决各种问题,大家可以留言分享自己遇到过的性能问题,及分析过程和最终的解决方案,丰富这个套路~
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
精选软件测试好文,快来阅读吧~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号