• 性能测试问题分析的通用方法
  • 发布于 1个月前
  • 90 热度
    0 评论

有同学问了这样一个问题:用JMeter执行压测,1000线程组,最后几个请求卡住了。网上的资料说可能是内存问题,因此将堆内存从2G改为了4G,重新尝试依然会卡住,有没有什么办法调整资源解决这个问题?


我仔细看了他的聚合报告,Max-rt已经到了70000+ms级别,且响应时间分布图峰谷值差距很大,于是便问了他下面这几个问题:
1.为什么要配置1000线程组?
2.什么业务场景,被测服务什么类型?
3.所谓的卡住,是请求没有返回响应报文吗?

4.电脑硬件配置是什么?在什么环境执行的性能测试?


这位同学的回复是这样的:有阶梯场景,服务的QPS差不多,最后想跑个1000看看。


从他的回复可以看出来,他在性能测试实践方面的经验并不多,也犯了新手最常见的几点错误,即:无脑高并发、测试执行没有章法(科学合理的场景设计)、对性能测试的基础理论理解不深、对压测工具的运行原理也不甚了解。
这篇文章,聊聊关于性能问题分析的话题,观点仅供参考。

首先聊聊并发的话题。

很多新手在学习实践性能测试时,会将并发、QPS、TPS和线程组的概念混淆。甚至有些同学会认为,注册用户数&在线用户数=并发,JMeter的线程组配置数值=并发,这样理解其实是走进了误区。初学者最容易犯的错误,就是认为性能测试就是找个工具模拟并发请求,不断加压然后看监控统计结果,其实不然。举一个常见例子:单接口调用没问题,用JMeter调试系统返回code:500。遇到这个问题该如何处理呢?


一般来说,当请求响应返回的状态码为500时,可以判断请求是通的,只是返回的响应体不是我们预期的结果。这个时候可以从这两点出发来分析问题:
1、查看被测服务日志,看详细的请求和响应信息,以及报错的堆栈信息。

2、对比单接口调试的请求内容和用JMeter组装的请求内容,是否存在差异。


为什么要对比JMeter的请求内容呢?因为它模拟请求的原理,是自己定义请求头和请求的body主体,和Postman等测试工具还是存在一定差异的,很多时候就是因为些许差异导致请求失败。对于性能测试的初学者,我建议在学习压测工具之前,先对网络协议如HTTP/TCP协议有一定的了解,否则只是学习压测工具的使用方法,很容易被卡在性能测试的门槛之外。

接着聊聊性能测试场景设计(执行策略)的话题。
对新手来说,性能测试最难的其实并不是瓶颈分析和优化,而是如何设置脚本并发和测试数据。下面是一些常见的工作案例,我会先介绍案例,然后举例说明测试策略(以JMeter为例)。
案例名称 脚本并发策略/测试数据策略 服务配置/并发推荐数值
新服务上线 梯度递增压力/参数化 4C8G/20-100
性能优化验证 梯度递增压力/参数化 4C8G/10-40
负载均衡验证 梯度递增压力/参数化 4C8G/10-60
参数配置调整验证 恒定并发压力/参数化 4C8G/固定数值
业务/技术逻辑调整验证 恒定并发压力/参数化 4C8G/固定数值
一些经验之谈:
1.绝大多数场景,第一次压测都推荐梯度递增方式,这样便于找到性能拐点。
2.固定并发压力只适用于其他条件不变,只有某一个影响因素变更的情况下使用。
3.一般都推荐先梯度,找到性能拐点定位问题后,再通过固定并发方式去验证优化是否生效。
4.单独的性能测试环境很重要,如果环境无法独立,建议听领导的要求压测一波统计数据出个报告就行。
5.测试数据记得一定要参数化,一定不要用同一个或同一批数据去反复压测(功能测试都更新数据更何况性能)。
以上都是经验之谈,新手小白可以照抄,但遇到问题建议不断调整去试错和验证,不要照着剧本念戏。

最后回到本文标题,聊聊性能问题分析的通用方法
从我的角度理解,我认为几乎大多数的技术问题,都可以参照如下的六个步骤:
1-说明现象:发生了什么(请求卡住,没有返回响应报文)。
2-说明事实:什么场景做了什么操作导致了这个现象(测试环境1000线程组压测)。
3-寻找数据:通过日志、监控等方式,寻找一切可以帮助你分析问题的数据(服务端日志是否有你的请求访问记录,是否有报错或异常堆栈;监控的失败请求数和未收到返回报文的请求数是否一致)。
4-分析问题:提出假设和观点,数据是否支撑你的假设和观点,如果是,就进一步向下分析(而不是根据现象直接去改服务的堆内存配置)。
5-得到结论:通过分析排除错误的论断,尝试修复并进行验证,观察数据是否朝预期方向改变(重复3和4步骤)。
6-优化验证:确认正确有效的优化方法,持续优化验证,直至达到预期目标或问题得到修复。
用户评论