性能分析思路和具体的实现之间，有一道鸿沟，那就是操作的能力。之前我为什么听不懂那些人的思路，其实是因为我没有操作的功底。
而有了操作的功底之后，还有一个大的鸿沟要越过去，那就是从操作到对监控计数器的理解。这一步可以说让很多性能测试人员都望而却步了。
但是这还不算完，这一步迈过去之后，还有一个跳跃，就是相关性分析和证据链分析的过程。如此一来，就会得到一张性能测试分析的能力阶梯视图，如下：
- 工具操作：包括压力工具、监控工具、剖析工具、调试工具。
- 数值理解：包括上面工具中所有输出的数据。
- 趋势分析、相关性分析、证据链分析：就是理解了工具产生的数值之后，还要把它们的逻辑关系想明白。这才是性能测试分析中最重要的一环。
- 最后才是调优：有了第 3 步之后，调优的方案策略就有很多种了，具体选择取决于调优成本和产生的效果。
性能分析思路大纲
- 瓶颈的精准判断；
- 线程递增的策略；
- 性能衰减的过程；
- 响应时间的拆分；
- 构建分析决策树；
- 场景的比对。
首先来讲，瓶颈的精准判断
对性能瓶颈做出判断是性能分析的第一步，有了问题才能分析调优。
之前有很多人在描述性能测试的过程中，说要找到性能测试中曲线上的“拐点”。我也有明确说过，大部分系统其实是没有明确的拐点的
再来看一下这张图对应的响应时间视图：
如果我们对 TPS 的增加控制得更为精准的话，那么这个 TPS 的增加是有一个有清晰的弧度，而不是有一个非常清晰的拐点。
但是至少我们可以有一个非常明确的判断，那就是瓶颈在第二个压力阶梯上已经出现了。因为响应时间增加了，TPS 增加得却没有那么多，到第三个阶梯时，显然增加的 TPS 更少了，响应时间也在不断地增加，所以，性能瓶颈在加剧，越往后就越明显。
那么我们的判断就是：
- 有瓶颈！
- 瓶颈和压力有关。
- 压力呈阶梯，并且增长幅度在衰减。
在这个 TPS 的曲线中，你还能判断出拐点在哪吗？
显然是判断不出来拐点的，但是我们根据图得出以下几个结论：
- 有瓶颈！
- 瓶颈和压力有关。
- 压力呈阶梯，并且增长幅度在衰减。
我们再来看一个 TPS 图：
这种比较有规律的问题，显然不是压力大小的原因。为什么呢？因为 TPS 周期性地出现降低，并且最大的 TPS 也都恢复到了差不多的水位上。所以，即使是压力降低，也最多降低最大的 TPS 水位，会让问题出现得更晚一点，但是不会不出现。
综合以上，如果画一个示意图的话，TPS 的衰减过程大概会如下所示：
- 随着用户数的增加，响应时间也在缓慢增加。
- TPS 前期一直都有增加，但是增加的幅度在变缓，直到变平。