性能测试 - 分析

 第一步：压力场景数据。

        在我看来，压力工具提供的数据只有两个曲线最为重要：一个是 TPS（你要是喜欢，也可以叫其他名字，像 RPS、HPS、CPS 之类，纠结名称并不是我们的关键），另一个是响应时间。

        不管是什么压力工具，只要能给出这两个曲线即可，即便是你自己开发的多线程压力工具也无所谓。不管是线程、协程，只要可以根据业务逻辑发出相应的压力即可。

        为什么说 TPS 和响应时间曲线最为重要，那其他的曲线，比如说吞吐量、点击率、错误率这些呢？错误率是有错误的时候才需要看的，这一点我想你应该不会有异议。而吞吐量、点击率之类的曲线，也必然会和 TPS 曲线是相同的趋势，所以我们不需要再单独分析。

        因此在第一步，我们只需要从压力场景中获取 TPS 和响应时间曲线就可以了。

第二步：分析架构图。

        接着是分析架构图，这一步我们需要做的是，看压力流量的路径。这主要是为了看分析链路的前后关系。如果业务逻辑复杂，部署也复杂，那我们就可以分为业务路径和部署路径。如果不复杂，那画一个路径就够了。

第三步：拆分响应时间。

        在这里，我要着重跟你强调一下，在性能分析过程中，拆分响应时间是分析的关键起点。有很多人在看到响应时间高的时候，总是不往下拆分就开始猜测系统的性能瓶颈在哪里。如果你也是这样，这种思路你一定要转换过来，不要总是在现象上纠结。

第四步：全局监控分析。

        话说现在很多看似拥有全局监控能力的工具平台，实际上还是会缺失一些计数器。所以，我们一定要根据性能分析决策树，来补全性能计数器。如果获取这些计数器，在当前的工具平台上实在有困难，那就通过其他的工具或命令来补充，这一点你要特别注意。

        很多公司往往只关注大层面的覆盖，忽视了具体计数器的完备。“全局监控分析”‘这一步有个关键，就是你要对你所看到的计数器有足够的了解。如果你看了数据之后，没有任何反应，那就说明你还没有达到分析的能力。这个时候，你要么就是来看专栏，要么就是去看书，要么就是去查度娘（虽然度娘在这个时候也不好使），要么就是放弃。

        那我们怎么知道一个全局计数器有没有问题呢？这就需要功底了，这些就是我经常说的计算机基础知识。性能分析的范围很大，不见得与它相关的所有知识的头上都会标着“性能”两个字。

        经常会有人问 GC 频率达到多少是合理的？这就是很难回答的问题。只要 GC 不影响系统容量，那就是可以的。所以，我们得先看 GC 和系统容量曲线之间的关联关系，然后再做判断。

        在性能分析中，没有哪个计数器可以直接跳出来告诉我们说“我有病！”，只能靠我们自己去判断它有没有病。

第五步：定向监控分析。

        看了全局监控计数器之后，我们通过判断分析，知道哪个方向上有问题后，才去做定向的监控。千万不要一开始就弄什么代码层分析、具体参数调整、SQL 调整啥的。不仅乱，而且不一定见成效。

        在“定向监控分析”这一步有个关键判断，就是能不能和上面的全局监控计数器对应。当我们想找一个栈的时候，要知道为什么要去找栈；当我们要判断 IO 参数有问题时，也要知道为什么要去找 IO 参数。

        这样一来，前后的逻辑关系就形成了我一直在 RESAR 性能工程中强调的一个词——证据链。

第六步：判断性能瓶颈点。

        有了证据链，就一定要来到性能瓶颈点的判断过程。比如说，我们在栈中判断有没有锁的存在，那至少你要在栈中找到这个锁有哪些线程在等待，哪个线程持有。再比如说，我们要判断一个 SQL 慢，那至少你要把 SQL 的执行过程拿出来，看到底是哪一步有问题。

        有了对性能瓶颈的判断，再往下走就是要找到解决方案。

第七步：确定解决方案。

        其实，知道瓶颈点在哪里，也并不一定知道有什么解决方案。就像有人看到了栈中有锁，但也不知道怎么解锁；有人知道 SQL 慢，但也不知道如何优化 SQL 一样。不过，这一步是性能项目体现价值的关键点。不管前面做得有多么辛苦，给出解决方案总是我们性能人员的重点。

        上述就是 RESAR 性能分析七步法，它在每个性能分析的案例中都会被使用。在具体的案例中，我们可能会选择其中的几步来做。当然，每个案例都走七步也是完全可以的。只是在我们分析的过程中，如果已经有了明确的问题点，就不用再往回分析了。

        比如说，如果我们已经知道了问题点，直接定向监控分析就可以了，不用再走第四步。还有就是，如果性能瓶颈不会导致响应时间长，而是出现其他的问题，可能就不需要走第三步。这些内容你将在后面课程的案例中看到具体的应用。