性能分析思路
前言
我还年轻的时候，经常听一些大会或者演讲。有些人说，思路逻辑非常重要。我那时就想，你肯定是瞎忽悠的，因为我怎么就没听懂你说的思路呢？
而现在轮到自己来写或者讲一些东西的时候，才发现他们说得很对，而我之所以不理解，也是有原因的。
性能分析思路和具体的实现之间，有一道鸿沟，那就是操作的能力。之前我为什么听不懂那些人的思路，其实是因为我没有操作的功底。
而有了操作的功底之后，还有一个大的鸿沟要越过去，那就是从操作到对监控计数器的理解。这一步可以说让很多性能测试人员都望而却步了。
但是这还不算完，这一步迈过去之后，还有一个跳跃，就是相关性分析和证据链分析的过程。如此一来，就会得到一张性能测试分析的能力阶梯视图，如下：
- 工具操作：包括压力工具、监控工具、剖析工具、调试工具。
- 数值理解：包括上面工具中所有输出的数据。
- 趋势分析、相关性分析、证据链分析：就是理解了工具产生的数值之后，还要把它们的逻辑关系想明白。这才是性能测试分析中最重要的一环。
- 有了第 3 步之后，调优的方案策略就有很多种了，具体选择取决于调优成本和产生的效果。
那么怎么把这些内容都融会贯通呢？下面我们就来说说性能测试分析的几个重要环节。
应该说，从我十几年的性能工作中，上面讲的这些内容是我觉得最有价值的内容了。在今天的文章中，我们将对它做一次系统的说明。我先把性能分析思路大纲列在这里：
瓶颈的精准判断
TPS 曲线
对性能瓶颈做出判断是性能分析的第一步，有了问题才能分析调优。
之前有很多人在描述性能测试的过程中，说要找到性能测试中曲线上的“拐点”。我也有明确说过，大部分系统其实是没有明确的拐点的。
举例来说，TPS 的视图如下：
显然，这是一个阶梯式增加的场景，非常好。但是拐点在哪呢？有人说，显然在 1200TPS 左右的时候。也有人说了，显然是到 1500TPS 才是拐点呀。但是也有人说，这都已经能到 2000TPS 了，显然 2000TPS 是拐点。
我们再来看一下这张图对应的响应时间视图：
是不是有人要说响应时间为 4.5ms 时是拐点了？
其实这些对拐点的判断，都是不合理的。如果我们对 TPS 的增加控制得更为精准的话，那么这个 TPS 的增加是有一个有清晰的弧度，而不是有一个非常清晰的拐点。
但是至少我们可以有一个非常明确的判断，那就是瓶颈在第二个压力阶梯上已经出现了。因为响应时间增加了，TPS 增加得却没有那么多，到第三个阶梯时，显然增加的 TPS 更少了，响应时间也在不断地增加，所以，性能瓶颈在加剧，越往后就越明显。
那么我们的判断就是：
- 有瓶颈！
- 瓶颈和压力有关。
- 压力呈阶梯，并且增长幅度在衰减。
如果你觉得上面的瓶颈还算清晰的话，那么我们再来看一张图：
在这个 TPS 的曲线中，你还能判断出拐点在哪吗？
显然是判断不出来拐点的，但是我们根据图得出以下几个结论：
- 有瓶颈！
- 瓶颈和压力有关。
- 压力也是阶梯的，但是并没有明确的拐点。
我们再来看一个 TPS 图：
看到这张图，是不是明显感觉系统有瓶颈呢？那么瓶颈是不是和压力大小有关呢？
这种比较有规律的问题，显然不是压力大小的原因。为什么呢？因为 TPS 周期性地出现降低，并且最大的 TPS 也都恢复到了差不多的水位上。所以，即使是压力降低，也最多降低最大的 TPS 水位，会让问题出现得更晚一点，但是不会不出现。
综合以上，如果画一个示意图的话，TPS 的衰减过程大概会如下所示：
- 随着用户数的增加，响应时间也在缓慢增加。
- TPS 前期一直都有增加，但是增加的幅度在变缓，直到变平。
在这样的趋势图中，我们是看不到明确的拐点的。但是我们能做的清晰的判断就是：有瓶颈！
所以对 TPS 曲线来说，它可以明确告诉我们的就是：
- 有没有瓶颈：其实准确说所有的系统都有性能瓶颈，只看我们在哪个量级在做性能测试了。
- 瓶颈和压力有没有关系：TPS 随着压力的变化而变化，那就是有关系。不管压力增不增加，TPS 都会出现曲线趋势问题，那就是无关。
这时你可能会问，为什么不看响应时间就武断地下此结论呢？其实响应时间是用来判断业务有多快的，而 TPS 才是用来判断容量有多大的。
响应时间的曲线
我们还是来看看响应时间，下面看一张响应时间图：
它对应的线程图是：
多明显的问题，随着线程的增多，响应时间也在增加，是吧。再来看它们对应的 TPS 图：
到第 40 个线程时，TPS 基本上达到上限，为 2500 左右。响应时间随着线程数的增加而增加了，系统的瓶颈显而易见地出现了。
但是，如果只让你看 TPS 曲线，你是不是也会有同样的判断？那就是：有瓶颈！并且和压力有关？所以说，其实 TPS 就可以告诉我们系统有没有瓶颈了，而响应时间是用来判断业务有多快的。
后面我们还会提到响应时间会是性能分析调优的重要分析对象。