来自极客时间教程不错的分享
第一步：压力场景数据。
在我看来，压力工具提供的数据只有两个曲线最为重要：一个是 TPS（你要是喜欢，也可
以叫其他名字，像 RPS、HPS、CPS 之类，纠结名称并不是我们的关键），另一个是响应
时间。
不管是什么压力工具，只要能给出这两个曲线即可，即便是你自己开发的多线程压力工具
也无所谓。不管是线程、协程，只要可以根据业务逻辑发出相应的压力即可。
为什么说 TPS 和响应时间曲线最为重要，那其他的曲线，比如说吞吐量、点击率、错误率
这些呢？错误率是有错误的时候才需要看的，这一点我想你应该不会有异议。而吞吐量、
点击率之类的曲线，也必然会和 TPS 曲线是相同的趋势，所以我们不需要再单独分析。
因此在第一步，我们只需要从压力场景中获取 TPS 和响应时间曲线就可以了。
第二步：分析架构图。
接着是分析架构图，这一步我们需要做的是，看压力流量的路径。这主要是为了看分析链
路的前后关系。如果业务逻辑复杂，部署也复杂，那我们就可以分为业务路径和部署路
径。如果不复杂，那画一个路径就够了。
第三步：拆分响应时间。
在这里，我要着重跟你强调一下， 在性能分析过程中，拆分响应时间是分析的关键起点。
有很多人在看到响应时间高的时候，总是不往下拆分就开始猜测系统的性能瓶颈在哪里。
如果你也是这样，这种思路你一定要转换过来，不要总是在现象上纠结。
第四步：全局监控分析。 2021/4/2
03 | 核心分析逻辑：所有的性能分析，靠这七步都能搞定
5/10
话说现在很多看似拥有全局监控能力的工具平台，实际上还是会缺失一些计数器。所以，
我们一定要根据性能分析决策树，来补全性能计数器。如果获取这些计数器，在当前的工
具平台上实在有困难，那就通过其他的工具或命令来补充，这一点你要特别注意。
之前我给一个银行客户分析问题的时候，他们说各个层面的监控数据都有。但实际情况却
是，与问题相关的计数器，他们是缺失的。这样的情况其实很普遍，很多公司往往只关注
大层面的覆盖，忽视了具体计数器的完备。
“全局监控分析”‘这一步有个关键，就是 你要对你所看到的计数器有足够的了解 。如果
你看了数据之后，没有任何反应，那就说明你还没有达到分析的能力。这个时候，你要么
就是来看专栏，要么就是去看书，要么就是去查度娘（虽然度娘在这个时候也不好使），
要么就是放弃。
那我们怎么知道一个全局计数器有没有问题呢？这就需要功底了，这些就是我经常说的计
算机基础知识。性能分析的范围很大，不见得与它相关的所有知识的头上都会标着“性
能”两个字。
经常会有人问 GC 频率达到多少是合理的？这就是很难回答的问题。只要 GC 不影响系统
容量，那就是可以的。所以，我们得先看 GC 和系统容量曲线之间的关联关系，然后再做
判断。
在性能分析中，没有哪个计数器可以直接跳出来告诉我们说“我有病！”，只能靠我们自
己去判断它有没有病。
第五步：定向监控分析。
看了全局监控计数器之后，我们通过判断分析，知道哪个方向上有问题后，才去做定向的
监控。千万不要一开始就弄什么代码层分析、具体参数调整、SQL 调整啥的。不仅乱，而
且不一定见成效。
在“定向监控分析”这一步有个关键判断，就是 能不能和上面的全局监控计数器对应 。当
我们想找一个栈的时候，要知道为什么要去找栈；当我们要判断 IO 参数有问题时，也要知
道为什么要去找 IO 参数。 2021/4/2
03 | 核心分析逻辑：所有的性能分析，靠这七步都能搞定
6/10
这样一来，前后的逻辑关系就形成了我一直在 RESAR 性能工程中强调的一个词——证据
链。
第六步：判断性能瓶颈点。
有了证据链，就一定要来到性能瓶颈点的判断过程。比如说，我们在栈中判断有没有锁的
存在，那至少你要在栈中找到这个锁有哪些线程在等待，哪个线程持有。再比如说，我们
要判断一个 SQL 慢，那至少你要把 SQL 的执行过程拿出来，看到底是哪一步有问题。
有了对性能瓶颈的判断，再往下走就是要找到解决方案。
第七步：确定解决方案。
其实，知道瓶颈点在哪里，也并不一定知道有什么解决方案。就像有人看到了栈中有锁，
但也不知道怎么解锁；有人知道 SQL 慢，但也不知道如何优化 SQL 一样。不过，这一步
是性能项目体现价值的关键点。不管前面做得有多么辛苦，给出解决方案总是我们性能人
员的重点。
上述就是 RESAR 性能分析七步法，它在每个性能分析的案例中都会被使用。在具体的案例
中，我们可能会选择其中的几步来做。当然，每个案例都走七步也是完全可以的。只是在
我们分析的过程中，如果已经有了明确的问题点，就 不用再往回分析 了。
比如说，如果我们已经知道了问题点，直接定向监控分析就可以了，不用再走第四步。还
有就是，如果性能瓶颈不会导致响应时间长，而是出现其他的问题，可能就不需要走第三
步。这些内容你将在后面课程的案例中看到具体的应用
