四、性能问题的分析
(下文以2022年2月A频道页面为例,均为dummy仿造后数据,也不代表整体情况)
4.1.如何衡量性能问题严重性
衡量性能问题严重性,是为了让大家意识到优化的必要性,以及急迫性。
4.1.0.进入性能黑榜前几名
同3.1.性能黑榜,不赘述。
4.1.1.看完全加载时长分布
见下图“可交互时长分布图”,一个记录代表一个用户。
即使不去统计,我们都能很明显的看出来,这个A频道页面:
·<1.5s的比例很低
· 1.5~3s占比最大
· >3s的比例相对而言很高,居然还有这么高比例在8s以上?
4.1.2.看时长分布比例
和开发说明问题严重性时,这个会很有代入感, 比如见下图,10%的Android用户在4.9s以上,是不是可以认为他们大部分都跳失了?
4.1.3.看和总体数据的对比
下图不用算都能明显发现,秒开率和 整体数据差异实在太大。
4.2.分析性能瓶颈-分析思路
首先要明确,性能分析主要是给相关页面的前端、开发同学看,给关心问题的测试同学看,所以我们可以拆分的更细节、更专业。 可以先分前端、后端2个大类:
4.3.分析性能瓶颈-前端环节
4.3.1.分终端分析
业务因素(具体不表),分终端是重点。
从可交互时长、秒开率、3秒+率、5秒+率,分别分析,都能论证--支付宝端问题更明显。
4.3.2.分阶段分析
下图将t1~t9 每个阶段打点情况可视化,并分析重点环节的差值。(打点逻辑由前端定义)
见图2可以明显观察到:
1、接口耗时太久,且2.12后变差明显(可以去追溯下2.12发生了什么);
2、LBS获取耗时很久,高于平均1倍以上,而取lbs是A频道页的关键逻辑。
4.3.3.分高中低端机分析
我们根据手淘的高中低端机评判标准,埋点获得数据。 平均时长,高中低各自占比,以及低端时长分布(也可选中高端)。 下图可发现,低端机比例很低(需要思考是否有必要重点优化), 但低端机超过3秒以上的比例远高于其他的(和总体的完全时间分布对比) 。
4.3.4.其他分析
包括:机型、系统等,可做参考。
4.4.分析性能瓶颈-后端环节
4.4.1.后端接口分析
主要从后端维度来分析
· 服务端链路逻辑,需要另做具体分析
· 分页面的处理逻辑,需要结合业务逻辑来看
这里可见,下图尽管是开始发起请求-》收到请求的全过程,但也严重超标。(几乎是标准值的2倍)
4.4.2.网络传输消耗分析
整个接口过程:
请求连接(apiConnect)--》服务端处理(apiRequest)--》数据下载(apiResponse)
细节不表了。
4.5.分析结论关键思路
1、数据差值越大的,样本量越多的,性能数据优化越明显
2、结合业务意义
3、为前端分析提供方向,更细节分析,还是要依赖前端的专业分析
还是以A频道为例, 从数据差值看,接口和lbs,和均值差异最大。 从样本量看,支付宝 流量占有一定比例, 因此,我们优化的重点在: 接口、LBS、支付宝端。
五、性能问题的验证
主要通过单页面性能趋势分析,主要2个作用
· 验证性能优化效果,做到可量化
· 及时洞察到页面性能向差的趋势,更具有主动性
5.1.性能恶化及时反馈
再如下图,今年1月,一次业务需求,致使性能变差,通过每周定时性能报表发送群里,马上发现。 推荐大家把性能趋势图,定时发送到群内,更及时发现。
5.2.性能优化效果验证
参考链接: https://zhuanlan.zhihu.com/p/51673262
R语言编程基础(U3010001)
R是用于统计分析、绘图的语言和操作环境,属于GNU系统的一个自由、免费、源代码开放的软件,它是一个用于统计计算和统计制图的优秀工具。
R语言语法通俗易懂,很容易学会和掌握语言的语法。而且学会之后,我们可以编制自己的函数来扩展现有的语言。这也就是为什么它的更新速度比一般统计软件,如SPSS、SAS等快得多。大多数最新的统计方法和技术都可以在R中直接得到。
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理