跳到主要内容

快速定位业务代码性能问题

最后 更新

快速定位业务代码性能问题

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

通过在线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 相较于传统工具和方法,能够自动化快速定位业务代码造成的性能问题,并智能化生成可解释的故障根因报告。

通过在线Demo故障注入平台,注入例如 运行额外任务抢占Pod可用的CPU资源 运行额外任务抢占Pod可用的memroy资源 增加POD FullGC频率 增加处理每个请求的CPU消耗 等故障来模拟真实环境中代码问题造成的性能问题。