7D性能项目日记7：​性能项目一定要有结论

一、前言

在我做过的每个性能项目的报告中，对应 RESAR 性能工程的容量场景（其他场景有另外的表达形式），都会列一个类似这样的表格：

同时也会把这个表格做成柱状图。

这是性能项目中的结论。通常我们在性能项目中只要有数据，就是可以列出这个表格的，但是这里面有些内容需要进一步解析一下。

二、结论解析（第一部分）

首先，历史峰值TPS是否可以拿到？如果可以拿到，是否准确？

这是一个在很多企业中都困难的数据。其实从技术上来说，这个值并不复杂，只要从有业务含义入口的日志中去统计就好了。通过趋势分析，从年-月-日-时-分-秒的层层细化，这个历史峰值的TPS就出来了。

但是！又不得不说但是了，在一些企业中，由于在前期系统设计的时候没有考虑过业务级的趋势统计，所以日志中请求级的统计是可以的，而业务级的统计是困难的。

还有，即便是有业务级的统计，那应该取业务TPS最高时的数据，还是取某个业务TPS最高时的数据成了另一个选择困难点。有人说，这不是一回事吗？还真不是。假设，现在有6个业务分别是：业务1、业务2、业务3、业务4、业务5、业务6。通过查看统计数据，看到业务TPS最高时的数据是这样的：

显然，总TPS是：650。但是可能出现的情况是，由于某个业务因为特定的活动或业务需要在某个时间高起来了。结果就变成了这样。

显然，这时的总TPS是：560。虽然总TPS没有上一个多，但是业务2却比上一个多。这时怎么办？

容量场景的最大TPS是以哪个为对比数据呢。有人说，那我们把一个表格中的业务2扩大到200以上不就好了，其他的也等比扩大。

这样显然是不合理的，都扩大了，对系统容量场景的最大TPS要求就增加了，如果测试结果中的最大TPS远远大于这个历史峰值的TPS，那还好，如果恰好就刚刚大了一点，当历史峰值的TPS等比扩大后，容量结果就变成不达标了，那就得考虑调优、加配置等手段以达标，这时显然就多出来很多工作。

所以，为了不随意扩大统计出来的TPS值，合理的方式是，将上面的两个表格设计成两个容量场景。

其次，目标TPS（这里我列的是历史峰值TPS的3倍）的值是否合理？

这里的几倍在具体的项目中是根据业务增长量来计算的，不是拍脑袋来的。如果历史数据是合理的，业务增长量也是合理的，这个表格才有存在的价值，并且最后的结论也才是精准的。

最后，最大TPS到底是什么值？如果我们给出这样的一个TPS趋势图（先不考虑这个图中有没有瓶颈，仅做为示例）。

这时的最大TPS是多少呢？根据图中的数据，最大值是943.8。那可不可以认为这个值就是最大TPS呢？

显然是不行的，因为图中可以明显看出来，TPS并没有长时间维持在943.8。那么我们判断最大TPS的条件就出来了，就是可以长时间维持住的TPS，也就是最大稳定的TPS，从这个图上看，长时间可以维持住的TPS应该在750左右。

这个值就是本文最上面表格中的最大TPS的来源。

另外：那么是不是这么简单判断就可以了呢？当然不是，还有另外的限制条件。这个疑问留给读者思考吧，可以留言到评论区。

三、结论解析（第二部分）

如果你以为上面的结论就够了的话，显然就过于单纯了。于是有同学说了：嗯，对，上面还没有资源数据，再加上各类资源使用率就完美了。像这样：

这里我只加一列CPU使用率以展示，实际上，我看有些同学在项目中，还会加上磁盘、内存使用率等数据。

我要说的是，这个不是我想表达的重点。如果你想列资源使用率，可以列在这里，但是，我觉得这个值描述不描述都可以。

如果你是想给运维团队一个参考的报警阈值，那没问题。可以单独给一个表格，因为目标变了，不是给性能结论，而是给运维建议。

我想说的结论的第二部分是：每个系统都要有瓶颈分析。

有人说，在迭代验证类型的性能项目中也要有吗？这样的项目中可以没有，但前提是，这样的性能项目中的瓶颈是已经知道的，不需要重复分析。

这里我提到的每个系统都要有瓶颈分析的做法是，在基准场景中做单业务最大TPS测试时就要有对应的性能瓶颈，即每个性能场景都要对应一个性能瓶颈。记录下这些瓶颈，就会形成分析调优文档。结构如下：

有了这个文档，才有了项目后续的优化方向。

有人可以会问了，如果我的目标TPS都达到了，是否还要判断性能瓶颈呢？在我的RESAR性能工程逻辑中，我认为是要判断性能瓶颈的，不管目标TPS有没有达到，因为不存在没有瓶颈的性能场景。但是，因为目标TPS已经达到了，所以这个瓶颈判断的重要性就没有那么高了，所以优先级可以降一降，如果项目中没有其他更重要的事情做了，再来判断不迟。

所以在我看来，一个完整的性能项目中一定要有明确的结论，也一定要有明确的瓶颈分析。