性能问题分析的通用方法

有同学问了这样一个问题：

用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为例)。

案例名称	脚本并发策略/测试数据策略	服务配置/并发推荐数值
新服务上线	梯度递增压力/参数化	4C8G/20-100
性能优化验证	梯度递增压力/参数化	4C8G/10-40
负载均衡验证	梯度递增压力/参数化	4C8G/10-60
参数配置调整验证	恒定并发压力/参数化	4C8G/固定数值
业务/技术逻辑调整验证	恒定并发压力/参数化	4C8G/固定数值

一些经验之谈：

1. 绝大多数场景，第一次压测都推荐梯度递增方式，这样便于找到性能拐点。
2. 固定并发压力只适用于其他条件不变，只有某一个影响因素变更的情况下使用。
3. 一般都推荐先梯度，找到性能拐点定位问题后，再通过固定并发方式去验证优化是否生效。
4. 单独的性能测试环境很重要，如果环境无法独立，建议听领导的要求压测一波统计数据出个报告就行。
5. 测试数据记得一定要参数化，一定不要用同一个或同一批数据去反复压测(功能测试都更新数据更何况性能)。
6. 以上都是经验之谈，新手小白可以照抄，但遇到问题建议不断调整去试错和验证，不要照着剧本念戏。

 

最后回到本文标题，聊聊性能问题分析的通用方法。

从我的角度理解，我认为几乎大多数的技术问题，都可以参照如下的六个步骤：

1-说明现象：发生了什么(请求卡住，没有返回响应报文)。

2-说明事实：什么场景做了什么操作导致了这个现象(测试环境1000线程组压测)。

3-寻找数据：通过日志、监控等方式，寻找一切可以帮助你分析问题的数据(服务端日志是否有你的请求访问记录，是否有报错或异常堆栈；监控的失败请求数和未收到返回报文的请求数是否一致)。

4-分析问题：提出假设和观点，数据是否支撑你的假设和观点，如果是，就进一步向下分析(而不是根据现象直接去改服务的堆内存配置)。

5-得到结论：通过分析排除错误的论断，尝试修复并进行验证，观察数据是否朝预期方向改变(重复3和4步骤)。

6-优化验证：确认正确有效的优化方法，持续优化验证，直至达到预期目标或问题得到修复。