输出有价值的性能报告
在性能项目中，有三个稳定在我看来是最为重要的，分别是性能方案、性能报告和调优报告。
今天是一起来看看性能报告。性能报告在项目中一般被称为“性能测试报告”。不过，接下来我会弱化“测试”这两个字，因为我会将整个性能项目各方面的内容都包含在内。
性能报告是一个性能项目的总结，是性能价值的最终体现，所以性能报告是非常重要的。就像我们减肥的时候经常会说“三分运动七分报告”，也就是说干货的辛苦都是留给自己体会的，报告如果做的不好，你再累、在辛苦，所有的付出都会付诸东流
但是，我看到当前性能市场中，很多性能报告都写得非常潦草，要么是数据收集得不完整，要么就是结论描写得不合理，让本来做的很好的性能项目没有体现出价值。
那怎么写出有价值的性能报告呢？今天我们一起来看看。
性能报告要给出明确的结论
在性能报告中，有一个环节应该是大部分人的恶梦，那就是给出明确的结论。
什么是明确的结论呢？我先给你列举几个常见的结论描述
- 容量场景结论：
描述1：服务器资源有明显性能瓶颈，建议升级或增加服务器；存储性能差，建议更换性能更好的存储；某服务有明显性能瓶颈，建议开发人员优化。
描述2：测试调优前 50TPS，测试调优 100TPS；也有人说，测试调优前有错，测试调优后没有错；测试调优前 CPU 使用率 90% ，测试调优后 CPU 使用率 50% ，测试调优前资源消耗 1000C 2000G，测试调优后资源消耗 500C 1000G
描述3：在 100 并发用户数下，某系统各功能点的平均响应时间均满足性能指标，功能点 TPS 总和为 3000，成功率均在 100%，各服务器资源平均使用率均在指标范围内；某系统在 200 并发用户时，系统处理能力为 4000TPS，继续增加并发用户数时，系统处理能力下降。
描述4：系统可支持 2000 万人同时在线，20000 人并发
- 稳定性场景的结论：
某系统在 400 并发用户下稳定运行了 120 小时，各交易平均响应时间小于性能指标要求，TPS基本呈平稳趋势，交易成功率为100%，各服务器资源使用率趋势平稳，满足性能需求指标
- 批量场景的结论：
A 业务联机批量（批量交易 ID：001、002、003）、B 业务联机批量（批量交易 ID：004、005）和C业务联机批量（批量交易 ID：006）执行时长为130000 毫秒、10000毫秒、1000毫秒、12000毫秒、10000毫秒、160000毫秒，满足性能指标要求。系统资源使用情况均满足指标要求。
此外，还有更多的结论描述，我就不一一列举了。
你咋一看这些结论，是不是觉得还挺合理的？确实是这样，如果我们只看一个报告的结论，很难看出结论本身有什么问题，我们最多能知道的就是这个结论偏向那个层面（技术层面或业务层面）
但是，在上述容量场景结论的几个描述中，描述 1 显然是不合格的结论，因为没有一句话是具体的。我不建议你用 “明显” 、 “建议” 、 “差” 、 “可能” 之类的词来写性能结论，这样的词都不够精准。
描述 2 看起来已经非常精准了，不过只描述了技术的角度，并没有给出系统是否可以支撑的结论；而描述3中规中矩，但是你心里要清楚，像“服务器平均使用率均在指标范围内”这样的描述，其中的这个“指标”是有具体值的；描述4非常直接说明了业务的结论，我觉得比较合理。
对于稳定性和批量场景的结论，你思考一下，我就不一一点评了。
说了这么多，你看会觉得奇怪，那到底性能结论要写成什么样呢？我们需要明确，性能报告表达的是业务系统的性能结论
曾经，某公司的性能工程师拿出一份报告给我看，我看过之后问：你这份报告是想表达战纪干得有多累吗？ 对方答：不是呀，我是想表达这个项目做的不错。 我说：你这里面并没有说哪里做的不错呀，我只看到了你们干得有多累…”
为什么会出现这种情况呢？主要是因为在他这样的报告中，把用了多少人，干了多长时间、做了那些工作都写的清清楚楚，但在结论部分却是非常笼统的描述，就像前面列举的实时业务容量场景的第一个描述那样。
于是，我告诉他，老板不需要看这样的报告，如果你要给老板做汇报，简明扼要即可，不用写那么花哨。我们的报告不是用来展现自己做的有多么辛苦，也请你务必牢记这一点。
先确定受众，在写性能报告
那性能报告应该写成什么样呢？这里在举两个例子 。
之前我做过一个性能项目，业务目标很明确：一小时完成 6000 万用户的完整业务流程。在项目结束之际，我写了一个 Word版的详细报告，大概80页左右，而在给客户汇报的时候，我只用了一份不到10页的PPT。
在第一页 PPT 上，我只写了两个数据：
并在汇报时说：“如果各位有兴趣，我可以大概讲一讲这个项目是怎么实现的。”这时候，你要注意，如果大家没反应，那就接着讲下去，不用讲得太细，只要笼统概括一下专业内容即可。
如果在你讲完第一页PPT后，有人开始聊待会儿去哪庆祝的话题，那就没必要再往下讲了。因为在汇报的场合里，专业技术的内容可能并不是受欢迎的话题，老板听得索然无味，业务方也听得一头雾水。要是有人对技术细节感兴趣，你到时候可以多讲两句。
总之，做性能汇报时，控场很重要，我们要引导现场，而不是被现场引导
我还做过一个性能项目，大概耗时三个月，几乎每天都加班加点，非常辛苦。在写汇报PPT时，我首先按逻辑把能想到的内容全都写了出来，总共写了120多页ppt（尽量写全，然后删减）
在汇报的前一天晚上，我看着这 120 多页的ppt 直犯迷糊，我没想到自己会整理出这么多东西。不过，我心里清楚，这些内容肯定不是汇报里该有的，所以，我决定删减，第一遍，我删了60页左右，还是太多了，第二遍，我删到了40页，还是觉得多，第三遍，我删了20页，这才感觉差不多了
于是，在那次很多的汇报会议中，我用这20页的ppt只讲了不到10分钟，在汇报结束时，我说：“这些就是我们的结论了，如果在场有技术人员对项目的具体实施过程感兴趣，可以看一下我们在会前发出的 200多页 Word 版本技术报告，要上各位没有疑问，我的汇报就到这里了”
汇报结束后，大家的反应都还不错。
性能报告应该有两种表现形式：
- 尽量详细的技术型报告：这种报告通常是 Word ，PDF，HTML形式
- 尽量简单的汇报型报告：这种报告通常是 PPT，Keynote形式
另外，多说一点，在汇报的场合，切忌与提出异议的人争论。即便有人提出的问题很尖锐，你也一定要磨圆了再回答，在这一过程中要不退不让、不卑不亢
性能报告具体怎么写
首先，我们需要明确的是，一个完整的性能报告基本上可以分为两大部分：
- 第一部分是执行场景之前的信息，也就是项目背景，测试分为，业务模型，性能指标，系统架构图，软硬件环境，压力工具及监控工具，数据，场景设计报告策略，监控设计
- 第二部分是执行场景之后的信息，包括场景结论整理、场景结论分析、结论、问题汇总、后续性能工作建议，运维建议
在你自己的项目中，性能报告倒不用这么完整，可以做相应的删减。
举例：一个用户完整的接口级请求是11个，但并不是每一个用户都会完整的走完这11个接口。按照业务模型中的比例算下来，100个TPS（一个T对应着一次接口请求）可以支持54个并发用户，也就是说平均单个用户需要的TPS是：
100 ÷ 54 ≈ 1.85
而当前的 TPS 是 1700 ，所以，当前系统支持的并发用户数是：
并发用户 = 最大TPS / 单用户级TPS = 1700 / (100÷54) ≈ 918
我们在根据并发度2.4%，来计算对应的在线用户数：
在线用户 = 并发用户 / 并发度 = 918 / 2.4% ≈ 38250
计算到这里，我们就可以进一步写出更为具体的结论：通过容量场景的结论可知，系统最大TPS为1700，系统可支撑最大918并发用户；系统可支撑最大的38250在线用户
对于容量场景的结论来说，我们写到这里就可以了