海外优质VPS
高性价比免备案主机推荐

干货 | 携程无线APM升级实践


作者简介

 

辛贵,携程无线研发总监。主要负责App基础框架研发相关工作,关注App开发框架、性能、质量、效率和新技术。

1、背景介绍

APM全称为Application Performance Management,即应用性能管理,对于一款成熟的App,各项性能指标的监控是必不可少的。公司内部早前有个1.0版本的APM系统,主要存以下问题:筛选功能薄弱、缺少日报和告警功能、功能混杂、且只支持单一App。鉴于以上问题,我们发起了APM2.0版本的重构,在开始之前,我们重新梳理了APM的定位,以及该做哪些功能。

最终,确定APM定位为数据报表+性能日报+监控告警+排障入口,具体如下:

  • 数据报表

    • 端到端精准数据报表

    • 多维度筛选功能支持

    • 多App报表支持

    • 实时报表

  • 性能日报

    • 核心性能指标提供邮件日报功能

    • 支持订阅功能

  • 监控告警

    • 适合告警的核心指标,进行告警

    • Crash率,JSError等告警

  • 排障入口

    • 支持多维度的异常数据、错误数据采样

    • 采样数据和内部系统打通

功能模块上,主要包括网络性能、页面性能、崩溃卡顿和专项性能四部分,下面章节会继续介绍。

2、主要功能

2.1 网络性能

网络请求性能是App的核心性能指标之一,APM平台以端到端的数据为基准,进行性能统计,这样最能反映用户的真实感受。

2.1.1 网络架构模型

如下图所示,App中的动态网络请求,都是通过自研的网络通讯框架发送到后端Gateway,Gateway再将服务转发给真实业务服务器。

干货 | 携程无线APM升级实践

几点简单说明:

  • 网络通讯框架和Gateway之间会通过TCP长连接进行通讯;

  • 网络通讯框架和Gateway之间数据协议为自定义契约格式协议;

  • 网络通讯框架可以将HTTP协议转换成自定义协议进行代理转发;

  • Gateway本身业务逻辑较少,只负责链路管理和请求路由转发,为了让用户有好的体验,我们做了全球部署;

  • 所有动态请求都通过网络框架发送,在这个点做好采样埋点,即可为APM报表提供精准数据源;

2.1.2 错误监控维度

端到端的网络请求异常数据,大多数是发生在链路的建立和数据传输上。由于我们是自己管理的TCP链路,因此对请求链路的可控性更加强,我们梳理了整个请求链路,对整个链路上存在异常的点,都定义了对应的code。参考下图: 

干货 | 携程无线APM升级实践

 主要以下code:

Code 定义 说明
-202 请求序列化失败 极小概率出现
-203 无可用链路 比例较高,无法连接到服务器,即为常见的网络不稳定
-204 发送请求失败 socket send失败,极小概率
-205 读取响应出错 链路异常,读不到指定长度的响应头
-206 响应反序列化失败 极小概率出现
-212 链路异常断开 包括客户端网络异常和后端主动断开
-213 读取不到响应 比例较高,即为常见的超时

以上错误code,主要是聚焦在自建TCP链路层面的异常,对于标准的HTTP Error,比如HTTP的4xx,5xx也会记录,一般出现这些错误的时候链路本身并不会出现错误(限TCP通道)。

2.1.3 监控的维度与目标

主要监控端到端请求的成功率和耗时两个数据维度。

  • 请求成功率

    • 计算方式:请求成功次数/(请求成功次数+请求失败次数)

    • 目标 – 用户交互场景:目标99%+

    • 目标 – 整体平均:目标98%+,包含启动、后台场景的请求,这部分请求成功率相对较低

  • 请求耗时

    • 计算方式:客户端发起请求为起始点,收到响应并序列化完成为结束点

    • 目标 – 用户交互场景:后端处理耗时+300ms(RTT时间)

2.1.4 APM报表

下面几张截图是网络性能模块设计的报表: 

干货 | 携程无线APM升级实践

上图是分版本,业务部门的性能概览数据,蓝色的字体,都是可以点击进行过滤筛选的。

干货 | 携程无线APM升级实践

上图是按照具体服务号,列出该服务的成功率、总耗时、服务端处理耗时、样本量、还有错误code分布。 

干货 | 携程无线APM升级实践

每个表格后面都有一个采样功能,点击该按钮,即可进行采样,选择一批错误或者是耗时较长的设备ID,点击设备ID,可以跳转到内部排障系统,查看更多详细信息,进行整个问题的排查。 

干货 | 携程无线APM升级实践

上图是内部排障系统中的一个小工具,可以根据一条链路ID来把该链路上的所有请求有序排列展示, 这对于日常排障非常有帮助,可以极大的提高网络问题的排障效率。

2.1.5 性能优化实践

以下是我们在进行端到端网络性能优化过程中的一些实践经验,简单介绍几个效果较好的优化方案。

  • 自定义通讯协议 使用自定义通讯协议,自管理链路,可以对请求中的每一个环节都做到完整的控制,对于故障排查和后续的性能优化会更加有价值。

  • 合理选择ServerIP 实际上包含两个场景的serverIP选择,一个是App刚启动时候默认使用的ServerIP,另一种是Server端下发适合的ServerIP之后的使用策略;几点经验, 国内场景,同一运营商效果较好,海外场景,服务器在海外部署,比通过加速通道回到国内源站效果要好,启动场景,根据timezone选择ServerIP比较合适;

  • 合理设置超时时间 超时时间设置过小,比如3s,成功率会比设置成15s的明显要低,所以可以根据服务的时效性,合理设置超时时间;

  • 支持重试 符合幂等性的服务,设置可以重试,可以大幅度提升成功率;


2.2 页面性能

2.2.1 页面性能统计方案

页面性能是关系到用户替换最重要的性能指标,如何去度量一个页面的性能,是没有一个通用的标准的。

一般在收到统计页面性能需求的时候,开发人员最常规的做法是在页面初始化的时候,设置一个时间点,然后在渲染所需的一个(组)服务发送完,页面渲染之后,设置一个结束点,两者相减,就是页面的可交互时间。

这种做法的统计是准确的,但是需要每个页面都去做这个逻辑,对于一些复杂页面,对于不同的业务逻辑,需要做多套这样的性能埋点处理。且后续随着业务的迭代,性能统计的逻辑还需要确保没有问题。

对于业务开发来说,这无疑是大大增加了工作量,我们希望能有一个框架层的方案,去统计页面渲染完成或者是可交互时间点(Time To Interactive)的性能,以便让业务开发人员从性能埋点中解放出来。

首先考虑到了页面截屏+像素点检测的方案去检测页面渲染完成时间点,思路如下:

  • 页面截屏,按照一定比例,去掉头部+底部部分

  • 将中间部分分隔成6块

  • 每个小块随机取点,检测像素点的相似度

干货 | 携程无线APM升级实践

按照这个思路实现并灰度上线了这套检测方案,基本准确的检测出页面渲染时间,但是也存在一些问题:

  • 性能损耗严重,每次截屏时间100ms

  • 对于一些骨架屏类的页面,会被当做页面渲染完成

  • 因为是随机取像素点,对于简单页面,页面检测的次数有一定的随机性

由于以上问题,这个数据上线之后,没能推广给业务开发同事去使用。继续优化,我们发现:

  • 页面渲染完成的时候,一般都有文本

  • 文本扫描的性能损耗比页面截屏低

在这两个观点支撑下,我们对检测方案做起了重构,将页面截屏+像素点的随机选取,替换成页面组件扫描+文案检查。大致流程如下:

干货 | 携程无线APM升级实践

  • 页面初始化开始,遍历页面所有元素,检测text

  • 如果text所在坐标在页面头部(20%)/尾部(25%)区域,忽略 Text >= 2组, 认为检测成功

  • 一轮检测之后,未检测成功,等待50ms进行下一轮检测

  • 总共检测10s,否则超时

以下视频是我们检测的demo,三个页面分别不同的技术栈,Native/CRN/H5, 可以看到,基本都是在内容加载完成的时候,toast弹出来提示页面检测完成。

干货 | 携程无线APM升级实践

该方案虽无法确认页面内元素是否完全渲染完成,但可以确定页面已经有内容,用户可以进行交互。所以我们将文案检测成功的时间点当做页面可交互的时间点,以此来作为页面的TTI(Time To Interactive, 后文使用TTI缩写)性能。

2.2.2 页面性能报表

上线之后,我们看到APM报表的数据,能比较真实的反映页面性能。

下图是APM平台上的页面TTI性能报表,支持多维度的筛选过滤,也支持采样功能。

干货 | 携程无线APM升级实践

对于每一个(组)页面,还能显示页面的TTI耗时分布,这对业务BU进行性能优化非常有帮助,简单相加就可以计算出页面TTI性能的95线,90线耗时。

干货 | 携程无线APM升级实践

在TTI性能表格的第一列,有一个页面类型,我们给每一个页面一个类型,每种类型设置一个TTI性能基准,TTI性能如果在基准之内的,显示绿色,超过基准20%的,显示红色,表示需要优化。以下是我们定义的基准,业务部门研发同事的页面性能优化以此为标准。

干货 | 携程无线APM升级实践

2.2.3 页面TTI性能优化

在配合业务团队研发同事进行页面TTI性能优化的过程中,积累了一些经验和优化方案。

  • 主线程耗时任务异步化

    • 将一些耗时,且在主线程操作的任务,调度到后台线程异步执行,可提升页面加载性能

  • 网络请求prefetch可大幅度降低页面TTI时间

    • 网络请求预取,即在页面跳转之前,将下一个页面需要的数据,预先获取回来,进入页面时候,只需要使用已经获取到的缓存数据

    • 可以大幅度提升页面性能,机票,酒店列表页面采用之后,页面TTI性能够有约40%左右的提升;

  • 预执行下一页面必须执行的任务

    • 对下一个页面必须执行的任务,在当前页面提前执行掉

    • 在下一个页面会下载离线包,优化为在当前页面下载下一页面可能使用的离线包;

  • CRN框架层的一些优化

    • 如果有使用ReactNative框架的话,强烈建议升级到0.61及其以上版本,并在Android平台开启hermes引擎;

    • RN提供的接口,大多是异步的,但异步接口在首屏加载,通讯频繁的场景,耗时不可控,可以换成同步API;

  • PreRender

    • 简单来说就是延迟页面跳转,利用延迟的时间进行页面的加载;

    • 只要延迟时间控制的好,对用户感知来说,就是页面在平滑的切换;

2.3 崩溃卡顿

崩溃卡顿系统,和大家常用的崩溃采集系统基本一致,这里不过多介绍。经常有用户投诉说遇到了闪退,但工程师在后台Crash收集系统里面却搜索不到对应的Crash日志。

技术的角度来说,是可以理解的,因为没有哪个Crash收集 SDK能够捕获所有的Crash,即便是操作系统也有一些不能捕获的,在iOS上也经常遇到App Crash之后在系统的设置里面,找不到对应的Log。

2.3.1 用户行为Crash

为了辅助统计用户遇到Crash的情况,我们在App启动的时候,去检测用户上次使用过程中是否有遇到Crash,如果有则上报上来,再开发成如下的用户行为Crash报表: 

干货 | 携程无线APM升级实践

判断用户是否有Crash策略大致如下:

  • 启动App或者页面切换时候,持久化页面信息;

  • App被切换到后台时候,清空掉持久化的页面信息;

  • 启动App时候,检查上次的页面信息,如果上次页面启动时间和当前时间相差较短,则认为出现了Crash;

以上方案不能完全准确的统计用户是否遇到Crash,有些Case无法捕获,但多个版本纵向对比还是有意义的, 且随机采样几个用户行为进行分析,发现确实有Crash出现;

2.3.2 自定义异常上报

在开发过程中,经常会有各种Exception需要处理。大多时候开发人员直接将exception print出来,不做其他处理,也有部分Exception的处理需要单独埋点,后续再开发报表,这样做是比较严谨的,但是工作量偏高。

为了解决这些问题,我们提供了logException的API,以及如下的报表,方便开发人员直接上报Exception。上报之后,APM的报表会按照title(图中的Category)和subTitle(图中的Message)两级的方式组织报表,并提供采样功能,方便问题的排查分析。

干货 | 携程无线APM升级实践

3. 总结

本文主要介绍了我们为了监控App的网络性能、页面性能和稳定性这三个核心性能指标而开发的APM系统,实践下来,发现APM系统在以下几个方面对比较有价值:

  • 让我们对线上App的实际运行的性能数据有了更加清晰直观的了解;

  • 各项核心指标的监控和性能日报对线上App的稳定运营提供保障;

  • 为我们各项性能优化提供了标准和数据支撑,按照标准去优化,优化之后有报表数据支撑;

  • 推动业务开发团队进行性能优化,让业务开发团队更加重视自己的产品性能质量;

本文介绍的只是APM系统的核心部分,实际上还有大量定制功能无法一一展开,比如告警和性能日报、自定义报表、各类专项性能等。希望我们在网络性能、页面性能和稳定性方面的实践经验对大家有所启发。

注:“携程技术”微信公众号后台回复“apm”,可下载讲师分享PPT。

【推荐阅读】

  • 近万字长文详述携程大规模应用RN的工程化实践

  • Node.js在携程的落地和最佳实践

  • 携程 Trip.com App 首页动态化探索

  • 加载速度提升15%,携程对RN新一代JS引擎Hermes的调研

  • 《携程技术2019年度合辑》,送给爱学习的你

干货 | 携程无线APM升级实践

 “携程技术”公众号

  分享,交流,成长

《干货 | 携程无线APM升级实践》原文地址:http://mp.weixin.qq.com/s?__biz=MjM5MDI3MjA5MQ==&mid=2697269379&idx=1&sn=1227a77caf29ae0e732d976f3f909540&chksm=8376efb7b40166a1b9e1cd491bac4763c8cdba9d089808bf0431e1ae23256e9246ef1924bc24

赞(0)
本站所刊载内容均为网络上收集整理,本站不保证其真实性和准确性,所有内容仅供大家娱乐参考。如有异议,请与本站联系,会尽快处理争议内容。VPS主机推荐 » 干货 | 携程无线APM升级实践

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址