常见性能问题分析

╰+攻爆jí腚メ 2023-09-26 16:49 18阅读 0赞

性能测试大致分以下几个步骤：

*  需求分析
 *  脚本准备
 *  测试执行
 *  结果整理
 *  问题分析

今天要说的是最后一个步骤——“问题分析”；

### 需求描述 ###

有一个服务，启动时会加载一个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 工具对perf.data进行解析

perf -i perf.data &> perf.unfold

3、第三步

将perf.unfold中的符号进行折叠：

./stackcollapse-perf.pl perf.unfold &> perf.folded

4、最后生成svg图：

./flamegraph.pl perf.folded > perf.svg

到这儿可以生成函数调用火焰图，如下图：

![图片][e9ef8fa22801429b89308c9eede22772.jpeg]

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

### 结尾 ###

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

如果你不想一个人野蛮生长，找不到系统的资料，问题得不到帮助，坚持几天便放弃的感受的话，可以加入我们的QQ群：**746506216**，大家可以一起讨论交流，里面会有各种软件测试资料和技术交流。

--------------------

### 资源分享 ###

**下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 `【保证100%免费】`**

![在这里插入图片描述][b9a9eea1ed5c42429c5e383b00ba6e0c.png_pic_center]

![在这里插入图片描述][d96b58a511f84668b59f3f620964da07.png_pic_center]

[e9ef8fa22801429b89308c9eede22772.jpeg]: https://img-blog.csdnimg.cn/e9ef8fa22801429b89308c9eede22772.jpeg
[b9a9eea1ed5c42429c5e383b00ba6e0c.png_pic_center]: https://img-blog.csdnimg.cn/b9a9eea1ed5c42429c5e383b00ba6e0c.png#pic_center
[d96b58a511f84668b59f3f620964da07.png_pic_center]: https://img-blog.csdnimg.cn/d96b58a511f84668b59f3f620964da07.png#pic_center