性能问题分析的通用方法
有同学问了这样一个问题:
用 JMeter 执行压测,1000 线程组,最后几个请求卡住了。网上的资料说可能是内存问题,因此将堆内存从 2G 改为了 4G,重新尝试依然会卡住,有没有什么办法调整资源解决这个问题?
我仔细看了他的聚合报告,Max-rt 已经到了 70000+ms 级别,且响应时间分布图峰谷值差距很大,于是便问了他下面这几个问题:
为什么要配置 1000 线程组?
什么业务场景,被测服务什么类型?
所谓的卡住,是请求没有返回响应报文吗?
电脑硬件配置是什么?在什么环境执行的性能测试?
这位同学的回复是这样的:有阶梯场景,服务的 QPS 都差不多,最后想跑个 1000 看看。
从他的回复可以看出来,他在性能测试实践方面的经验并不多,也犯了新手最常见的几点错误,即:无脑高并发、测试执行没有章法(科学合理的场景设计)、对性能测试的基础理论理解不深、对压测工具的运行原理也不甚了解。
这篇文章,聊聊关于性能问题分析的话题,观点仅供参考。
首先聊聊并发的话题。
很多新手在学习实践性能测试时,会将并发、QPS、TPS 和线程组的概念混淆。甚至有些同学会认为,注册用户数 &在线用户数=并发,JMeter 的线程组配置数值=并发,这样理解其实是走进了误区。
初学者最容易犯的错误,就是认为性能测试就是找个工具模拟并发请求,不断加压然后看监控统计结果,其实不然。举一个常见例子:单接口调用没问题,用 JMeter 调试系统返回 code:500。遇到这个问题该如何处理呢?
一般来说,当请求响应返回的状态码为 500 时,可以判断请求是通的,只是返回的响应体不是我们预期的结果。这个时候可以从这两点出发来分析问题:
1、查看被测服务日志,看详细的请求和响应信息,以及报错的堆栈信息。
2、对比单接口调试的请求内容和用 JMeter 组装的请求内容,是否存在差异。
为什么要对比 JMeter 的请求内容呢?因为它模拟请求的原理,是自己定义请求头和请求的 body 主体,和 Postman 等测试工具还是存在一定差异的,很多时候就是因为些许差异导致请求失败。
对于性能测试的初学者,我建议在学习压测工具之前,先对网络协议如 HTTP/TCP 协议有一定的了解,否则只是学习压测工具的使用方法,很容易被卡在性能测试的门槛之外。
接着聊聊性能测试场景设计(执行策略)的话题。
对新手来说,性能测试最难的其实并不是瓶颈分析和优化,而是如何设置脚本并发和测试数据。下面是一些常见的工作案例,我会先介绍案例,然后举例说明测试策略(以 JMeter 为例)。
一些经验之谈:
绝大多数场景,第一次压测都推荐梯度递增方式,这样便于找到性能拐点。
固定并发压力只适用于其他条件不变,只有某一个影响因素变更的情况下使用。
一般都推荐先梯度,找到性能拐点定位问题后,再通过固定并发方式去验证优化是否生效。
单独的性能测试环境很重要,如果环境无法独立,建议听领导的要求压测一波统计数据出个报告就行。
测试数据记得一定要参数化,一定不要用同一个或同一批数据去反复压测(功能测试都更新数据更何况性能)。
以上都是经验之谈,新手小白可以照抄,但遇到问题建议不断调整去试错和验证,不要照着剧本念戏。
最后回到本文标题,聊聊性能问题分析的通用方法。
从我的角度理解,我认为几乎大多数的技术问题,都可以参照如下的六个步骤:
1-说明现象:发生了什么(请求卡住,没有返回响应报文)。
2-说明事实:什么场景做了什么操作导致了这个现象(测试环境 1000 线程组压测)。
3-寻找数据:通过日志、监控等方式,寻找一切可以帮助你分析问题的数据(服务端日志是否有你的请求访问记录,是否有报错或异常堆栈;监控的失败请求数和未收到返回报文的请求数是否一致)。
4-分析问题:提出假设和观点,数据是否支撑你的假设和观点,如果是,就进一步向下分析(而不是根据现象直接去改服务的堆内存配置)。
5-得到结论:通过分析排除错误的论断,尝试修复并进行验证,观察数据是否朝预期方向改变(重复 3 和 4 步骤)。
6-优化验证:确认正确有效的优化方法,持续优化验证,直至达到预期目标或问题得到修复。
版权声明: 本文为 InfoQ 作者【老张】的原创文章。
原文链接:【http://xie.infoq.cn/article/f5a20e5c9ea21b0600453d4d4】。文章转载请联系作者。
评论