一些性能分析方法论，如SEI负载测试计划过程、RBI方法论、性能下降曲线分析法等，只是停留在概念和方法论，并无落地细节，它们完全没有必要存在。
在任何一个搜索工具搜“性能测试方法论”关键字，基本上都可以看到很多复制来复制去的内容，基本都在描述一个测试的实施过程，并且这些实施过程也都基本停留在测试阶段。如下面几段关于“SEI负载测试计划过程”的描述：
SEI load Testing Planning Process，关注负载测试计划的方法，目标是产生“清晰、易理解、可验证的负载测试计划”。
SEI负载测试计划过程包括6个关注的区域：目标、用户、用例、生产环境、测试环境和测试场景。
- 生产环境与测试环境的不同：由于负载测试环境与实际的生产环境存在差异，因此，在测试环境上对应用系统进行的负载测试结果很可能不能准确反映该应用系统在生产环境上的实际性能表现，为了规避这个风险，必须仔细设计测试环境
- 用户分析：用户是对被测应用系统性能表现最关注和受影响最大的对象，因此，必须通过对用户行为进行分析，依据用户行为模型建立用例和场景
- 用例：用例是用户使用某种顺序和操作方式对业务过程进行实现的过程，对负载测试来说，用例的作用主要在于分析和分解出关键的业务，判断每个业务发生的频度、业务出现性能问题的风险等。
都是偏向“测试”执行过程的内容，理论提出者Mark McWhinney，1992年，他在SEI和John H. Baumert写了一个类似CMMI的内容：《Software Measures and the Capability Maturity Model》。Mark McWhinney描述了四个级别的软件度量和成熟度模型，分别是：可重复级、可定义级、可管理级和可优化级，其中描述的也都是过程、影响、成本、质量、稳定性这些内容。
像这样的定义本身没有问题，但如果是像CMMI那样，企业只是拿个证，并不遵循它来做具体的项目，那这个理论就没意义。
性能行业中，想实际落地，可从SEI又得不到具体指引，这就是问题。因为要有具体性能容量、性能瓶颈的分析落地，才能体现性能项目最终的价值。而这部分缺失，使得很多性能从业人员没有可参考的成长路径。
所以性能分析的核心逻辑很关键。性能工程师最缺的就是分析思路。有很多人会各种工具，但是这些分析工具的数据拿出来应该如何组装成一串逻辑，又是难点。
如果从“测试”这个行业来看，性能分析的完整案例可以说非常少见。如果从运维或其他职位的角度来看的话，倒还是有一些的。但是纵观大部分的性能案例，都缺少一个提炼到更高一层的分析方法论。**把性能分析思路给固定下来。**即“RESAR性能分析七步法”，这只是RESAR性能工程的一部分，并不是整个RESAR性能工程。
1 RESAR性能分析七步法
跟着RESAR性能工程理论，分析逻辑：
1.1 压力场景数据
压力工具提供的数据只有两个重要曲线：
- TPS
- 响应时间
不管啥压力工具，能给出这两个曲线即可，即便是你自己开发的多线程压力工具也无所谓。不管是线程、协程，只要可以根据业务逻辑发出相应的压力即可。
其他曲线，如吞吐量、点击率、错误率这些呢？
- 错误率，有错误才要看
- 吞吐量、点击率之类的曲线，也必然会和TPS曲线是相同趋势，所以无需再单独分析
1.2 分析架构图
看压力流量的路径。为了看分析链路的前后关系，若业务逻辑：
- 复杂，部署也复杂，那我们就可以分为业务路径和部署路径
- 不复杂，那画一个路径即可
1.3 拆分响应时间
性能分析的关键起点。
很多人在看到响应时间高时，总是不往下拆分，就开始猜测系统的性能瓶颈在哪里。这种思路一定要转换过来，不要总纠结现象。
1.4 全局监控分析
很多看似拥有全局监控能力的工具平台，还是缺失一些计数器。所以，要根据性能分析决策树，补全性能计数器。如果获取这些计数器，在当前的工具平台上实在有困难，那就通过其他的工具或命令来补充。
给一个银行客户分析问题的时候，他们说各个层面的监控数据都有。但实际情况却是，与问题相关的计数器，他们是缺失的。很多公司往往只关注大层面覆盖，忽视了具体计数器的完备。
关键
要对你所看到的计数器有足够了解。若你看了数据后，无任何反应，说明你还没分析能力。这时：
- 要么来看专栏
- 要么就是去看书
- 要么就是去查度娘（虽然度娘在这个时候也不好使）
- 要么就是放弃
怎么知道一个全局计数器有没有问题呢？
就需要功底，这些就是我经常说的计算机基础知识。性能分析的范围很大，不见得与它相关的所有知识的头上都会标着“性能”两个字。
经常会有人问GC频率达到多少是合理的？这很难回答的问题。只要GC不影响系统容量，那就是可以的。所以，我们得先看GC和系统容量曲线之间的关联关系，再判断。
在性能分析中，没有哪个计数器可以直接跳出来告诉我们说“我有病！”，只能靠我们自己去判断它有没有病。
1.5 定向监控分析
看了全局监控计数器后，判断分析，知道哪个方向有问题后，才去做定向监控。千万不要一开始就弄什么代码层分析、具体参数调整、SQL调整啥的。乱还不一定有效。
在“定向监控分析”这一步有个关键判断：能不能和上面的全局监控计数器对应。
- 想找一个栈时，要知道为什么要去找栈
- 要判断IO参数有问题时，也要知道为什么要去找IO参数
这样一来，前后的逻辑关系就形成了我一直在RESAR性能工程中强调的一个词——证据链。
1.6 判断性能瓶颈点
有了证据链，就一定要来到性能瓶颈点的判断过程。比如说，我们在栈中判断有没有锁的存在，那至少你要在栈中找到这个锁有哪些线程在等待，哪个线程持有。再比如说，我们要判断一个SQL慢，那至少你要把SQL的执行过程拿出来，看到底是哪一步有问题。
有了对性能瓶颈的判断，接着即找到解决方案。
1.7 确定解决方案
其实，知道瓶颈点在哪里，也并不一定知道有什么解决方案。就像有人看到了栈中有锁，但也不知道怎么解锁；有人知道SQL慢，但也不知道如何优化SQL一样。不过，这一步是性能项目体现价值的关键点。不管前面做得有多么辛苦，给出解决方案总是我们性能人员的重点。
上述就是RESAR性能分析七步法，它在每个性能分析的案例中都会被使用。在具体的案例中，我们可能会选择其中的几步来做。当然，每个案例都走七步也是完全可以的。只是在我们分析的过程中，如果已经有了明确的问题点，就不用再往回分析了。
若已知问题点，直接定向监控分析，不用再走step 4。若性能瓶颈不会导致响应时间长，而是出现其他问题，可能无需step 3。
2 总结
性能分析核心逻辑，是RESAR性能工程中具体的性能瓶颈分析指导。没有它，就没有分析的具体落地步骤。落地时不遵循这核心逻辑，它也就没有价值。
七步法涉及到对应知识体系，像在构建性能分析决策树、查找性能瓶颈证据链时，就要强大的技术基础知识做支撑。
RESAR性能分析七步法，是做任何性能瓶颈定位时必须要依赖的逻辑，帮助解决了很多没有遇到过的问题。性能分析中，你只需要知道下一步做什么，终会找到瓶颈原因。
3 FAQ
系统思维方式要求对任一系统的研究，须从它的组成、序列、功能、相互关系、历史发展等多方面考察，综合地揭示系统本质特征。综合性是其系统思维的显著特征，表现为：
- 微观分析与系统整体相结合
- 理论与经验相结合
- 定性与定量相结合
『RESAR 性能分析七步法』已经具备。
响应时间的拆分，卡死了，去做全链路检测吧，比较困难，这个拆分时间具体咋分析呢？
- 日志
- apm工具
- 抓包
死就死在了 响应时间拆分上， 没落地方案。 想着弄skywolking，但是go语言服务，和开发运维商量了两次 最终还是没落地。 请问还有别的落地方案吗？
elastic 的apm加*就可。
之前做过的调优案例中，用的是什么样的分析逻辑？ 以前的分析，就是看结果对比目标，达标的不管了，没达标的根据监视结果，从资源，设定（数据库和中间件等），代码，数据库几个层面分析。 性能分析七步法，也不是在每个分析中都必须全部做，你看我后面的案例中，有些就会跳跃了。 从我的经验上来看，不管是什么样的场景，严格按这七步来都是没有问题的，当实际分析中，可以根据对系统和问题的熟悉程度适当减少步骤。
像那种百万级或者更大的并发，也用jmeter这种工具找N台机器做分布式压测吗，如果机器不够用咋办，或者有啥更好的方式。
自己分布式压力工具。如果压力机确实不够用，那也只能加机器或降目标。
通过架构图，找出路径，是否有点大材小用？ 还得从架构图里，分析出哪些潜在的“阻力点”或“阻力区”，也就是潜在可能瓶颈点，如带宽或速度约束。 然后要去看概要设计，专门去找这些潜在的约束，在设计视角，如何进行技术方案的对比和选择技，让约束始终在在设计的视野范围内。 最终体现在实现的时候，有性能分析工具，专门来测定那些“阻力点”或“阻力区”的性能余量。
通过架构图能干很多事。不建议一下看到具体细节点，因为细节点太多，要有逻辑地分析，就不会盲目。