qq_37756660的博客

写性能报告，其实是对前面的所有工作做一个总结。因此，性能报告中的所有数据来源都是确定的。至于表达的形式，我建议你直接明了，不要啰嗦。另外，尽量使用图来表达结论，不要用表格，因为表格无法呈现比较直观的趋势。性能报告作为性能项目中最重要、最能体现性能价值的一个输出文档，我们做性能的人必须要学会编写。而在编写的过程中，我们一定要先考虑清楚受众是谁，然后从受众的角度考虑报告内容的表现形式。在做汇报时，我们一定要做到简明扼要，不过分表达，但也不能遗漏。

通过这节课，我给出了确定生产系统配置的思路。而做这件事情的前提是，我们对被测环境有明确的容量预期。在有了容量预期，并且对系统进行了调优之后，我们就可以通过这两个步骤把各个性能参数确定下来：1. 发起压力；2. 通过监控和场景执行数据，判断每个重要的性能参数的具体配置值。我强调一下，这一步需要我们非常细心，试验也要做很多遍。由于性能相关参数有很多，这就需要我们结合性能配置树中罗列出的每个性能配置，一一确定。你可能会觉得这是一个非常费时费力的活。

在搭建这个课程所用的系统时，我采用了微服务的架构，这也是当前主流的技术架构。微服务电商项目技术全解析。这里面主要介绍了该项目的一些预备知识、系统结构、主要技术栈以及核心组件。此外，还有相关的运行效果截图。这节课的内容包括了物理环境的说明、技术组件的具体搭建过程、示例系统的搭建过程以及运行效果。经过上面所有的步骤，我们就把整个课程涉及的所有技术组件、示例系统完全搭建起来了。1. 核心优势任务调度：为集群系统中的任务提供调度服务，自动将服务按资源需求分配到资源限制的计算节点；

如果你要做这样的异常场景，那么请你事先考虑好你的预期。我们对异常场景最基础的预期就是，在异常出现的时候，系统能快速恢复，这也是我们做异常场景的价值。如果不能快速恢复，业务也就随着异常掉下去了，这时候我们就要提 Bug、提风险。在这节课中，我们模拟了应用级异常、操作系统内部异常、容器级异常和整个操作系统级异常，在当前的微服务架构中，这些都是经常出现的异常场景。当然，它们并不能覆盖微服务架构中的全部异常场景。你可以根据上节课讲的异常范围图，把缺少的异常场景设计出来，以覆盖全面。

针对异常场景，在性能行业中各有各的看法，并且谁都说服不了谁，这就导致每个企业做的异常场景范围都不一样。同时，行业中又有很多关于混沌测试、非功能测试的不同说法。因此，异常场景一直都没有在性能项目中固定下来。而在 RESAR 性能工程理念中，对于有压力背景的异常场景来说，我觉得由性能人员来完成它，是责无旁贷的。通过这节课，我想告诉你的就是异常场景的范围应该有多大，以及设计的逻辑应该是怎样的。有了这些内容之后，异常场景的覆盖率就会足够全，并且也有章可循了。

正如我们前面所说，在稳定性场景中，我们要关注的就是“运行时长”和“业务累积量”这两个指标。只要达到了这两个指标，稳定性场景即可结束。磁盘不足的问题这样的问题在稳定性中也是经常出现的。因此，我们在稳定性场景运行之前，最好预估一下会用到多少磁盘。像日志之类的增长速度，一定要做好循环日志，不要保留太长时间。如果你想保留，那就移到其他地方去。数据库文件损坏的问题这是扩展磁盘空间导致的问题。虽然在操作的过程中，磁盘看似成功扩展了，但由于操作的不当导致了数据库文件损坏。

今天我们讲了稳定性场景的两个要点，分别是运行时长和压力量级。要想把稳定性场景做得有意义，这两点是必备前提条件。同时，你要记住一点，稳定性场景是为了找出业务积累的过程中出现的问题。所以，如果业务积累量不能达到线上的要求，就不能说明稳定性场景做得有意义。此外，在这节课中，我们也分析了物理内存增加的问题。在内存的使用上，特别是在这种 Kubernetes+Docker 的架构中，资源分配是非常关键的。不要觉得 Kubernetes 给我们做了很多自动的分配工作，我们就可以喝咖啡了。

从基准场景做完之后，我们来到了容量场景，这是一个非常大的变化。在这个场景中，我们解决了几个问题并最终给出了结论：第一个阶段：分析了压力工具参数化的问题，解决了 TPS 不断降低、响应时间不断上升的问题。第二个阶段：分析了数据库索引，解决了 TPS 低的问题。第三个阶段：分析了资源争用，解决了多容器跑到一个节点上的问题。第四个阶段：分析了网络争用和 Redis 的 AOF，解决了 TPS 不稳定的问题。第五个阶段：递增压力，给出最终系统整体容量的结论。

我们这节课的分析过程还是挺坎坷的，光是场景运行就执行了三次，可见即便基准容量已经测试通过了，容量场景也没那么容易运行起来。在第一阶段的分析中，我们主要定位了在压力线程不变的情况下，TPS 随时间增加而增加的问题。请你注意，压力不变时，TPS 平稳才是正常的。在第二阶段分析中，我们定位了索引不合理的问题。这样的问题算是比较常见的，定位起来比较简单，优化起来也比较容易出效果。在第三阶段分析中，我们解决了资源使用过于集中的问题，其中，我做了资源的重新分配，并且也看起来挺正常了。

看到这里，你是不是觉得容量场景还挺复杂的？确实是这样。容量场景不仅技术上有需要关注的点，在管理上，也有需要关注的点。我之所以对容量场景做这么多的描述，是因为容量场景对性能项目来说太重要了。当前的市场上经常提到的全链路压测，其实就是容量场景的一个具体场景。因此，在这节课中，我把容量场景中重要的地方再给你捊了一遍，希望你能对容量场景重视起来。另外，我想给你一个小提醒，即便是所有的基准场景都执行得很好，容量场景也不是必然会顺畅，所以你要做好心理准备。

在这节课中，我们在分两个阶段描述了两个问题。第一个问题比较简单，是全表扫描没加索引的问题，我们在前面也有过描述。之所以在这节课中又说一下，是因为 SQL 把 CPU 全都吃光了，而这种状态才是全表扫描在性能中比较常见的问题。第二个问题和内存溢出有关，对于 Java 的应用来说，我们要把内存的溢出找出来，就必须理清楚代码的逻辑，知道哪个变量在哪里定义，谁在取值，谁在使用，还有层级关系也要划分清楚。现在的开发工具已经非常友好了，可以告诉我们代码的前后调用关系。

在这节课中，虽然我们的优化并没有让 TPS 明显增加，但是因为分析的技术细节不一样，我也非常完整地记录了整个分析过程。在第一阶段的分析中，我们运用的还是之前提到的分析思路。不同点在于，对于一个非常成熟的固定组件，我们要想优化它，就要去了解它的架构，找到它的相关性能参数。因为在实际的性能项目中，面对这样的组件，我们往往没有时间去纠结内部的实现，需要非常快速地作出判断。如果时间允许，你倒是可以慢慢折腾。其实理解一个技术组件的原理，并没有想像中的那么高不可攀、深不可测，只要耐心看下去，你总会成长。

在这个接口中，我们遇到了好几个问题。先抛开问题和复杂度不说，我想表达的是，在性能优化过程中，问题是像洋葱一样一个个剥开的。虽然有可能一个优化动作就可以产生很好的效果，但是我们一定不要着急，要慢慢分析一个个问题。回顾一下我们对这个接口的所有分析优化过程。在第一阶段中，我们修改线程池产生了效果，但也出现了新问题；在第二阶段中，我们解决了查询大量数据导致内存被耗光的问题；在第三阶段，我们解决了索引的问题；在第四阶段中，我们重新调配了资源，让系统的调度更加合理。

在这节课中，我们做了三个阶段的分析优化。在第一阶段中，我们修改了 JDBC 池，虽然 TPS 有上升的趋势，但是，新问题也同样出现了：TPS 非常不稳定，还有断断续续的情况。在第二阶段中，我们分析了内存溢出的问题，定位出了原因并优化了内存问题。虽然我们在 TPS 曲线上明显看到了优化的效果，但仍然没有达到理想的程度。在第三阶段中，我们分析定位了 SQL 的问题，这是非常合乎逻辑的。因为我们在第二阶段中修改了 SQL，所以到了第三阶段，就要直接到数据库中做相应的定位。

在这节课中，我们有两个阶段的分析。在第一个阶段中，我们定位了数据问题。对于性能来说，数据是非常重要的基础资源，而数据的合理性直接影响了测试的结果。经常有初入性能行业的人讨论：性能脚本中的数据到底应该用多少？我觉得这是一个非常明确的问题，在所有的性能场景中，使用的资源都应该按真实发生的业务逻辑来确定，有且只有这样，才能保证结果是有效的。在第二阶段中，我们定位了一个有意思的问题，而这个问题的复杂性在于整体的架构。

在这节课中，我们讲了两个阶段的性能分析。第一个阶段比较简单，就是一个查询的问题。对于查询来说，在实时交易的过程中，最好能够精准查找。如果出现范围查询，那就必须要有分页。不过，如果是大范围的查询，那不仅会对网络造成压力，同时还会对应用、数据库等各层都产生非常明显的压力。所以，在出现范围查询时，我们必须做好技术选型。当业务必须做这样的范围查询时，你可以考虑换组件，像大数据这样的思路就可以用起来了。第二个阶段有点麻烦，虽然我们花了很多时间精力，但是到最后没有找到根本原因。

现在，我们总结一下这节课。“哎，哎，你先别总结呀，问题都没解决完，你看这不是还有 TPS 掉下来的情况吗？“年轻人，别捉急，饭都得一口一口吃，问题自然要一个一个解决了。这个问题，会放在后面的课程中解决。在这节中，我们从 TPS 不高开始，一直分析到了具体的 SQL，看似是两个简单的索引就搞定的事情，逻辑也并不复杂，但是，这个分析思路非常重要。对于第二个问题，我们从错误数据查到了日志中出现的死锁信息，这一点大部分人应该都可以做得到。只不过，能立即想到参数冲突的，就是有经验的人了。

在这节课中，我们看到 APM 工具也有无能为力的地方。所以说，当我们分析到一个具体组件之后，要想再往下分析，就得靠自己的技术功底了。在出现请求不均衡的时候，我们一定要先去看负载均衡的逻辑有没有问题。当看到 ES client 不均衡时，我们去看了 iptables 的原理，在发现 iptables 只有一个转发规则的时候，接下来要做的当然就是重刷转发规则了。在 ES client 转发均衡了之后，我们在 ES data 单节点上又看到 CPU 使用率过高。

当我们看到一个接口已经满足了业务要求时，从成本上来说，我们不应该花时间再去收拾它。但是，从技术上来说，我们对每一个接口的性能结果，都要达到“知道最终瓶颈在哪里”的程度。这样才方便我们在后续的工作中继续优化。在这节课的例子中，我们从 si cpu 开始分析，经过软中断查找和纯网络测试，定位到了 Kubernetes 的网络模式，进而我们选择了更加合理的网络模式。整个过程穿过了很长的链路，而这个思维也是在我在宣讲中一贯提到的“证据链最后，还是要强调一遍，

这节用登录功能串了一个完整的性能分析场景。在前面代码修改的部分，性能分析过程是比较快的，我们就是看看哪里的代码逻辑会消耗更多的时间。这个思路就是前面提到的 us cpu 的证据链。而接下来我们在分析 Auth 服务的时候，是先从拆分时间开始一步步走到代码里的，其中最核心的部分是从 CPU 到栈，再到 BLOCKED 的判断。当我们看到栈上有 BLOCKED 的时候，要记得打印栈信息。但是因为有些锁会非常快速地获取和释放，所以就可能会出现打印栈时，看到等某个锁的栈信息，但是整个栈文件中却没有这把锁的情况。

在打开首页这个接口的基准场景中，涉及到了很多方面的内容。从一开始的信息整理，比如访问路径、查看代码逻辑、场景试运行等，都是在为后面的分析做准备。而当我们看到响应时间高，然后做拆分时间这一步，就是我一直在 RESAR 性能工程中强调的“分析的起点因为在此之前，我们用的都是压力工具上的数据，只是把它们罗列出来就好了，没有任何分析的部分。对于拆分时间，我们能用的手段有多种，你可以用你喜欢的方式，像日志、APM 工具，甚至抓包都是可以的。拆分了时间之后，我们就要分析在某个节点上响应时间高的时候，要怎么做。

在这节课中，我们通过压力工具中的曲线，判断了瓶颈的存在。然后通过 SkyWalking 拆分了响应时间。在确定了响应时间消耗点之后，我们又开始了两个阶段的分析：第一个阶段的证据链是从现象开始往下分析的，因为 st cpu 是指宿主机上的其他应用的消耗导致了此虚拟机的 cpu 资源被消耗，所以，我们去宿主机上去查了其他的虚拟机。这里我们要明确 CPU 资源应该用到什么样的程度，在发现了资源使用不合理之后，再接着做第二阶段的判断。在第二阶段中，我们判断了 CPU 运行模式。

根据 RESAR 性能工程理论，在性能场景中，我们按执行过程，可以将场景分为四类：基准场景、容量场景、稳定性场景和异常场景。这些场景各有目的，在这节课中，我们主要描述了基准场景的逻辑，并给出了实例。基准场景有两个重要的目的：1. 获得单接口最大 TPS；2. 解决单接口基准场景中遇到的性能问题。这两个目的对我们很重要，都是为了容量场景打基础的。在这节课中，主要想让你感受一下性能分析的过程。当然了，我们最后的这个优化效果其实还没有达到我对性能的要求。

在我的逻辑中，全局和定向必须要分开，这一点我在前面跟你强调过，不分开就会导致资源浪费，并且我们需要的数据还有可能是缺失的。另外，请你注意，监控的全面性直接取决于项目级性能分析决策树的构建，也就是说用什么工具并不是关键，关键在于这些监控工具有没有把性能分析决策树的树叶都覆盖全。在选择监控工具时，我们主要考虑的是成本、范围、层次、使用的延续性等因素。只有合理的监控策略和监控工具，才能让性能分析决策树真地落地，才能让性能瓶颈证据链的查找具有可能性。

在这节课中，我努力地把在线用户数、并发用户数、并发度和 TPS 之间的关系做了深入的剖析。如果你在跟不同职位的人沟通时，请注意关心一下他们想说的并发、在线、TPS 到底在哪个层级，因为要是不在一个频道上，是无法达成一致结论的。在你做性能项目时，如果可以取得其中的关键数据，那就可以根据我们前面讲的相应公式做计算。而这个计算逻辑，不止是对 HTTP 有效，对任何一个协议也都是有效的。在这节课中，也把在线用户数、并发用户数、并发度和 TPS 之间存在的误解做了详细的说明，也对一些行业谬传做了深入的解析。

在这节课里，我们一起学习了性能场景中的数据到底应该做成什么样子。对于造数据而言，方法有很多，我们不用拘泥于某种造数据的手段，只要能快速造出足够的数据量就好。在 RESAR 性能工程中，性能场景需要两类数据：铺底数据和参数化数据。其中，铺底数据需要满足这三个条件：一定要造出符合生产量级的数据量；数据量要真实模拟出生产的数据分布；数据要真实可用。参数化数据需要满足这两个条件：参数化数据量要足够；要符合真实用户的输入数据。有了以上这些知识，我们就不会在造数据时出现混乱的情况了。

最后，我们再一起回顾下这一讲的重点内容。在业务模型抽取时我们要注意几个关键点：1. 抽取时间：抽取时间一定要能覆盖生产系统的峰值时间点；2. 抽取范围：抽取的范围要足够大，因为在一些场景中，即便不是峰值，但由于某个业务量较大，也会出现资源消耗大的情况；3. 业务比例在场景中的实现：得到业务模型之后，我们在性能场景中一定要配置出对应的业务比例，不能有大的偏差。只要做到以上几点，性能场景基本上就不会和真实业务场景有大的差异了。

在这节课里，把一个性能方案该有的内容以及要写到什么程度，都梳理了一遍。希望能给你一些借鉴。性能方案是一个性能项目的重要输出。如果你是在项目中做快速迭代，可能并不需要写如此复杂并且重量级的文档。因为文档里描述的很多工作都已经做过了，你可能只需要跟着版本去做迭代比对就好了。但对于一个完整的项目来说，性能方案就显得极为重要。因为它指导了这个项目的整个过程。在性能方案中，我们强调了几个重点：业务模型、性能指标、系统架构图、场景设计、监控设计等，它们都会对整个项目的质量起到关键作用。

RESAR 性能分析七步法，这是性能分析方法论中最重要的核心逻辑。不过，这些内容“孤篇盖全唐”的可能性很小，毕竟性能分析涉及到的所有细节无法在短短两节里尽述。所以，把我认为最重要的部分都给你描述出来了，当你在实际应用时，可以按照这个思路，实现你的性能分析决策树和性能瓶颈证据链。前提是，你要理解你的系统，理解你的架构，并且要理解讲的分析逻辑。在这节课中，讲解了两个重要的内容：性能分析决策树的构建，以及性能瓶颈证据链的查找。这是我们在每一个性能问题的分析过程中，都必须经历的。

我们这节讲的性能分析的核心逻辑，是 RESAR 性能工程中具体的性能瓶颈分析指导。没有它，就没有分析的具体落地步骤。但是如果在落地时不遵循这个核心逻辑，它也就没有价值了。在这七步法中，会涉及到对应的知识体系，像在构建性能分析决策树、查找性能瓶颈证据链时，我们就需要强大的技术基础知识做支撑。如果一个人不具备全部的基础知识也没关系，可以组织一个团队共同来做这件事情。对于我来说，RESAR 性能分析七步法，是我做任何一个性能瓶颈定位时必须要依赖的逻辑，它帮助我解决了很多以前没有遇到过的问题。

从“性能测试”到“性能工程”的思路转换，并不是一句话，也不是画个图，写个文章，做个 topic，就可以尽述的。我们只有在工作中将上面说的每一步应用到具体的工作中去，才是真正的工程。这也是我为你梳理性能概念的初衷。我们再一起回顾下这节课的重点内容。性能需求指标：没有业务指标就没有技术指标，而我们的工作就是让业务指标（比如并发用户数、在线用户数等）和技术指标（比如 CPU、IO 等）对应起来。在不同的性能场景中要定义好不同的性能需求指标，有些是自己看的，有些是给别人看的。性能场景。

从“测试”到“工程”，看似是一个简单的描述变化，其实是完全不同的做事逻辑。先在这里下一个定义——RESAR 性能工程。我们平时说的性能工程，是将 IT 中的各种技术应用到具体的性能项目中的过程。而我提到的RESAR 性能工程，是对性能项目过程中的各个具体的动作做更详细的描述，使之可以成为可以落地的具体实践。“RESAR 性能工程”这个名字是我自己定义的，你不用去网上搜索，现在还搜不到。下面我会为你描述 RESAR 性能工程的过程。

一个项目中应该具有的关键性能动作，也都将在这个课程中得到体现。比如说：脚本中哪些关键点会影响到最终的结果，具体是如何影响的？业务模型到底能不能完全符合生产环境统计出来的数据？性能报告到底应该如何下结论？性能团队应该给运维什么样的具体建议？上线之后，怎么评估性能项目做得好不好？……总之，希望你能看到一个性能项目真实的落地过程，知道在一个性能项目的各个阶段应该做什么事情以及要做到什么样子，从一个更为宏观、全局的视角，真正吃透性能。这也是一名优秀的性能工程师必须要具备的能力。