软件测试知识点|常见性能问题分析

性能测试大致分以下几个步骤&＃xff1a;

1. 需求分析

2. 脚本准备

3. 测试执行

4. 结果整理

5. 问题分析

今天要说的是最后一个步骤——“问题分析”&＃xff1b;

有一个服务&＃xff0c;启动时会加载一个1G的词表文件到内存&＃xff0c;请求来了之后&＃xff0c;会把请求词去词表里做模糊匹配&＃xff0c;如果匹配到了就向一个后端服务发送一条http请求&＃xff0c;拿回数据之后&＃xff0c;返回给客户端的同时&＃xff0c;向mysql记录请求的唯一标识和一个请求次数的标记&＃xff1b; 
其中有几个关键函数 
模糊匹配&＃xff08;fuzzyMatching&＃xff09; 
后端请求函数&＃xff08;sendingRequest&＃xff09; 
拼装请求函数&＃xff08;buildResponse&＃xff09; 
记录mysql请求次数标记&＃xff08;signNum&＃xff09;

第一组&＃xff1a;完全随机请求词&＃xff0c;qps达到1k时&＃xff0c;服务器未见异常&＃xff0c;cpu、内存、带宽均未满&＃xff0c;qps无法继续提升&＃xff1b;

• 分析&＃xff1a;由于此服务后端连接了其它服务&＃xff0c;所以在压测之前&＃xff0c;要确认后端服务不会成为瓶颈点&＃xff0c;目前的状态很可能是后端服务限制了被测服务的性能&＃xff1b;此时可以检查后端服务所在机器的各项指标&＃xff0c;或者查看本机的连接状况&＃xff0c;一般后端服务无法处理&＃xff0c;而被测服务又会一直向后面请求的话&＃xff0c;timewait状态的连接会变得比较多&＃xff1b;

第二组&＃xff1a;解决后端服务的问题后&＃xff0c;第二组使用平均30个字的请求词&＃xff0c;来打压&＃xff0c;qps到400时&＃xff0c;cpu load已满&＃xff1b;

• 分析&＃xff1a;这种情况明显是由于fuzzyMatching函数计算效率的问题导致cpu满载&＃xff0c;从而无法提升qps&＃xff0c;使响应时间不断增大&＃xff0c;此时可以通过perf&＃43;火焰图来确定整个处理请求过程中响应时间长的函数&＃xff1b;此时需要评估压测数据是否合理&＃xff0c;如果线上平均请求词只有2个的时候&＃xff0c;此组测试明显不合理&＃xff0c;此时要开发进行性能优化就是浪费时间的&＃xff1b;如果评估测试数据合理&＃xff0c;可以再次更换短词数据进行压测验证猜测&＃xff1b;

第三组&＃xff1a;解决了上述两个问题之后&＃xff0c;使用完全随机请求词&＃xff0c;qps到达3k后降低至1k&＃xff0c;然后再次提升到3k&＃xff0c;如此反复&＃xff1b;

• 分析&＃xff1a;此时关注一下各项指标&＃xff0c;排除了以上的问题的话&＃xff0c;操作mysql慢的问题可能性大一些&＃xff0c;对这种需要高并发的系统来说&＃xff0c;直接读写mysql不是个聪明的解决方案&＃xff0c;一般会用redis做一层缓存&＃xff0c;这里说道的另一个问题就是开发设计不合理&＃xff0c;导致的性能问题&＃xff1b;

第四组&＃xff1a;将后端换做真实的服务来做整体压测&＃xff0c;发现qps最高只能到300&＃xff0c;此时检查各项指标&＃xff0c;发现入口带宽占满了&＃xff1b;

• 分析&＃xff1a;这次问题比较明显&＃xff0c;后端服务返回内容过大&＃xff0c;导致带宽被占满&＃xff0c;此时依然需要评估需求&＃xff1a;1、是否需要后端返回的所有数据内容&＃xff1b;2、评估更换万兆网卡的性价比&＃xff1b;3、是否可以通过技术手段优化带宽占用&＃xff0c;比如把一次请求分散到多组服务的多个请求&＃xff1b;

perf&＃43;火焰图定位函数问题

这里简单说一下如何使用perf&＃43;火焰图来直观的定位性能问题&＃xff1a;

perf

Perf 拥有了众多的性能分析能力&＃xff0c;举例来说&＃xff0c;使用 Perf 可以计算每个时钟周期内的指令数&＃xff0c;称为 IPC&＃xff0c;IPC 偏低表明代码没有很好地利用 CPU。Perf 还可以对程序进行函数级别的采样&＃xff0c;从而了解程序的性能瓶颈究竟在哪里等等。Perf 还可以替代 strace&＃xff0c;可以添加动态内核 probe 点&＃xff0c;还可以做 benchmark 衡量调度器的好坏。

• 使用举例&＃xff1a;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、第一步 
使用压力测试工具对程序进行打压&＃xff0c;压到程序拐点&＃xff1b; 
$sudo perf record -e cpu-clock -g -p 11110 
Ctrl&＃43;c结束执行后&＃xff0c;在当前目录下会生成采样数据perf.data. 
2、第二步 
用perf script工具对perf.data进行解析 
perf script -i perf.data &> perf.unfold 
3、第三步 
将perf.unfold中的符号进行折叠&＃xff1a; 
./stackcollapse-perf.pl perf.unfold &> perf.folded 
4、最后生成svg图&＃xff1a; 
./flamegraph.pl perf.folded > perf.svg

到这儿可以生成函数调用火焰图&＃xff0c;如下图&＃xff1a;

原生的perf可以直接定位C/C&＃43;&＃43;的程序&＃xff0c;通常编译debug版本的程序能看到更多的信息&＃xff0c;java、go等语言可以通过各自定制的工具来生成&＃xff0c;原理类似&＃xff1b;通过火焰图可以轻松定位到哪个函数的处理时间最长&＃xff0c;从而找到问题所在&＃xff1b;

本文YY了一个项目&＃xff0c;YY了一些场景来分析一些真实的性能问题&＃xff0c;平时的性能测试中遇到的问题远比文中列举的多&＃xff0c;有代码逻辑问题、服务器配置问题、服务部署问题、甚至需求合理性的问题&＃xff0c;每个问题都有自己分析定位的套路&＃xff0c;掌握了这个套路就可以解决各种问题&＃xff0c;大家可以留言分享自己遇到过的性能问题&＃xff0c;及分析过程和最终的解决方案&＃xff0c;丰富这个套路~

下面是配套资料&＃xff0c;对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库&＃xff0c;这个仓库也陪伴我走过了最艰难的路程&＃xff0c;希望也能帮助到你&＃xff01;

最后&＃xff1a; 可以在公众号&＃xff1a;程序员小濠 &＃xff01; 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享&＃xff01;&＃xff0c;其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

如果我的博客对你有帮助、如果你喜欢我的博客内容&＃xff0c;请 “点赞” “评论” “收藏” 一键三连哦&＃xff01;喜欢软件测试的小伙伴们&＃xff0c;可以加入我们的测试技术交流扣扣群&＃xff1a;310357728里面有各种软件测试资源和技术讨论&＃xff09;