降本思路
在A企业内部，线上业务稳定性标准为：达到业务核定TPS时，CPU利用率的峰值不超过60％，即为稳定状态。
在这个背景下，测试部门针对部分CPU消耗较高的系统进行了统一梳理和专项性能测试，旨在满足业务TPS要求时，通过性能测试及调优降低被测应用的峰值CPU利用率。若峰值CPU利用率出现明显下降，则减少部署节点的CPU核数，针对业务场景进行复测。若发现峰值CPU利用率依然低于60％且TPS无异常，则将生产环境部署节点的CPU核数减少，释放更多的资源用于其他业务的部署。配合生产监控手段，若在一定时间内无异常，则认为降本成功。
具体思路示意如图所示。
对图所示的降本步骤说明如下。
1)性能压测：对被测应用进行高并发压测。
2)性能评估：通过查看性能测试过程中的性能指标，评估其可能的优化点。性能指标包括TPS、响应时间、CPU利用率、内存占用率、代码响应时间、全链路拓扑等。
3)性能分析：包括如下3个维度。
❑针对CPU消耗较高的被测应用，进行CPU热点分析及线程追踪分析。以可视化报表查看应用在高CPU利用率时运行的代码段及线程ID，深度分析代码段源码及线程调用栈，定位高CPU利用率根因。
❑针对内存消耗较高的被测应用，通过内存透视分析，以低开销方法获取JVM的新生代、老年代、GC、堆外内存、内存对象、类对象等指标。通过可视化报表实时查看异常指标或曲线，分析与其对应的内存对象，定位根因。
❑针对代码响应时间长的被测应用，通过子方法调用分析，以实时字节码增强技术对代码中触发的子方法调用进行微秒级耗时分析。在定位至最耗时的代码段后，开启源码分析，查看源码逻辑并定位根因。
4)性能调优：针对找到的CPU、内存、线程、代码问题，与项目组沟通，进行修复。
5)降本验证：针对优化后的被测应用，使用相同的场景及并发数进行验证，确保被测应用的CPU指标、内存指标有所改善。针对已确认优化后的被测应用，降低CPU、内存配置，再使用相同场景及并发数进行性能测试，确认降配后的性能指标符合上线标准。
若降配后被测应用指标未达到上线标准，则从性能评估的步骤开始，再次进行分析。
降本案例
基于以上降本思路，A企业内部的实际系统调优过程如下。1)问题现象描述：在高并发压测场景下，系统中应用的平均CPU使用情况如图10-19所示，实际CPU利用率达到70.07％，最高达到100％。
图10-19 某应用CPU利用率2)定位过程描述：通过性能分析平台的热点分析，发现大部分CPU都消耗在日志爬栈操作过程中
CPU热点分析图
3)确定性能风险点：频繁的日志爬栈在高并发下会导致CPU消耗过大，影响整体应用体验。
4)提出优化建议：从开发规范角度来说，不建议通过行号来定位，因为这样做的成本太高，资源浪费太多，最好使用带有准确标志的输出日志字符串来明确哪段代码逻辑有问题。对于该案例，首先，建议将打印行号的参数％I、％L删除。其次，删除％method或者％m配置，目前Debug、Info、Warn、Error这些级别的日志使用的是同一套输出格式，即pattern配置相同，建议Debug和Info不要打印方法名和行号，直接打印Warn和Error就可以。
5)实际优化效果：通过修改配置，TPS从260笔/秒提升到320笔/秒，提升25％以上。
6)降本效果：应用服务器配置降低50％后，整体指标仍满足目标值。