此文档是如何分析报表性能问题针对仪表盘场景的补充,主要以demo中的景区旅游数据中心为例,分析仪表盘加载过程的关键请求,辅助运维支持人员初步判断仪表盘性能。
注意不同版本,请求的关键内容和分析过程是基本一致,但是请求路径名可能不一致,下图以25年03月的V11为例说明。
资源地址:景区旅游数据中心
所有仪表盘基本会有以下关键请求:
加载页面框架
这部分加载内容通常由产品决定,和仪表盘的复杂度关系不大,用户做不了什么的,如这部分不同机器不一样,主要和浏览器本身性能、网络下载速度有关
加载仪表盘定义
见上图,这部分和用户制作仪表盘复杂度有关,主要影响用户白屏时间体验,比如加的组件越多,图片越多,定义越大,下载时间可能就越久,当然如果定义的大小比较大,和现场网络就有较大关系
根据仪表盘定义,初始化仪表盘和组件
这部分性能和仪表盘复杂度有很大关系,主要影响用户白屏时间体验,加载关键内容有:
仪表盘页面背景,背景图很大的话,可能影响用户视觉体验
多数据集联动关系
筛选器显示值等,这个和取数有关系,也就是和数据库性能也会有关
组件自身初始化,如加载地图,就会加载地图相关框架脚本,组件类型越多,这部分脚本也会越多,同时浏览器端执行脚本性能耗时也会越久
图片等静态组件同步加载图片
根据上面初始化动作,假如一个仪表盘太大,又有滚动条,就会建议开启仪表盘的滚动加载提速
组件取数,根据组件依赖关系构建取数请求
这部分主要影响用户最终看到完整数据的体验,系统本身会合并组件取数请求,后来是流式返回,处理完一个组件就会输出一个组件的数据,但存在以下特殊情况
当在用户和smartbi节点之间放置了代理服务器,如ngix、smartbiproxy,有时会出现某个慢组件影响一批组件的性能响应。这是因为代理服务器默认是会有缓存的,即使是流式返回,代理也是缓存8k内容后再流式返回,不足8k会等待服务器继续输出方返回给浏览器。