Kindling-OriginX 使用指南：快速定位业务代码性能问题

应用的性能对用户体验至关重要，如何找出业务代码中的性能瓶颈并加以解决呢？简单来说，它指的是你的应用在运行过程中出现的性能瓶颈点，也就是导致应用运行变慢的核心问题。这些瓶颈点通常可以归结为一些耗时的操作、资源占用过多、算法未优化等等。解决这些性能问题可以让你的应用变得更快速、更高效。

进入产品官方网站[https://originx.kindlingx.com]，通过在线Demo进入故障注入平台，注入  [运行额外任务抢占Pod可用的CPU资源]  [运行额外任务抢占Pod可用的memroy资源] [增加POD FullGC频率] [增加处理每个请求的CPU消耗] 等故障来模拟真实环境中代码问题造成的性能问题。

本指南将展示如何使用 Kindling-OriginX 对业务代码中的性能问题进行快速定位，同时与传统方式进行简单对比。

传统方式

传统方式中主要通过各类 APM 工具，日志分析工具，性能压测等方法来发现业务代码中的性能问题。

性能分析工具

通过大量Tracing、Log、Metrics数据，再结合JVM、系统日志、中间件日志等各类数据，人工汇总分析定位，工作量极大，难以快速完成。以下图为例，Trace数据及调用栈既多又杂，实际处理中无从下手，且难以和Log、Metrics数据协同分析。

专家经验

往往根据经验或其他主观判断，采用代码Review的方式，逐个对性能代码就行优化，往往处理周期长且几乎完全依赖个别专家主观判断。

日志分析

通过长时间多轮次的日志打点追踪，记录跟踪性能问题点，通过日志分析与比对定位性能瓶颈。经常容易丢失故障现场，既需要多种相关软件支持，又需要有相关经验的技术专家，以下图为例大量日志分析也需要大量时间和人力。

压测分析

尽可能构建真实的使用环境，进行压力测试，查找并分析代码中可能存在的性能问题。压测环境难以和生产环境完成一致，不同的压测手段也导致其有很大的局限性。

传统方式中业务代码性能问题难以排查主要是由于缺乏可见性、依赖专家能力、复杂的应用架构、限制性调试工具以及不可重现性问题等因素的综合作用。为了更高效地排查业务代码性能问题，需要有现代化的方法和工具，提供自动化和全局化的支持，帮助开发人员更快地定位和解决问题。

---

使用Kindling-OriginX

Kindling-OriginX 对于发生在业务代码中的性能问题提供自动化、零侵入、高效便捷、极低性能损耗的解决方案。

针对每一条 Tracing 自动化分析

• 分类统计当下故障服务情况，清晰直观发现性能问题点。

• 聚合单个服务故障报告，聚焦重点问题。

  

智能化生成可解释的故障根因报告

• 简明扼要给出可解释的根因报告，任何人都能据此高效定位导致性能问题的原因。例如本例中给出根因是对应节点的Runq耗时高，存在CPU抢占。

• 报告包含 Trace 信息，描述、时间、耗时、TraceID等基本信息。

• 报告对节点链路调用情况及耗时数据进行详细对比分析。

  

• 提供节点详情、Trace 耗时情况对比及该时段对应日志。本例中结合给出的故障根因和问题时段的日志，即可确定性能问题所在位置。

• 提供各层级分段调用数据及单独的历史基线数据，使用户能够对代码执行的每一步都能了如指掌，通过耗时分析对问题方向提供明确指引。例如本例中runq耗时明显高于历史基线水平。

  

• 提供影响各条Trace数据的核心指标详情，帮助用户聚焦关键指标。报告中包含根因推导过程的详细数据及指标，既可还原推导过程又可帮助还原现场。例如本例中runq耗时高，则会针对runq相关的指标进行下钻分析。

  

  

 

Kindling-OriginX相较于传统工具和方法，能够自动化快速定位业务代码造成的性能问题，并智能化生成可解释的故障根因报告。

进入产品官方网站[https://originx.kindlingx.com]，通过在线Demo进入故障注入平台，注入  [运行额外任务抢占Pod可用的CPU资源]  [运行额外任务抢占Pod可用的memroy资源] [增加POD FullGC频率] [增加处理每个请求的CPU消耗] 等故障来模拟真实环境中代码问题造成的性能问题。

---