一、报表性能组成公式

在使用系统过程中，出现仪表盘、电子表格等报表打开性能不如预期，此时就需要分析性能瓶颈，找出优化方案。

先看一个性能公式：报表性能=浏览器端执行性能 + 网络下载性能+ 服务端执行性能。

其中服务端执行性能 = Smartbi服务端执行性能 + 数据库执行性能。

在排查性能问题的过程中，我们通常会按照以下顺序进行：

网络性能排查→服务端性能排查→页面执行性能排查→提交有效信息问题上报

接下来将分别介绍如何通过性能分析工具对这些步骤进行排查，以系统地定位性能问题。

二、性能分析工具

根据前面性能组成部分，每一块都需分析其性能瓶颈，主要借助到以下工具

2.1浏览器端性能分析工具

浏览器开发者工具可帮助诊断问题出在服务端响应、网络传输还是网页本身代码效率上，并且都可下载录制结果，便于后续上报问题分析。如chrome开发者工具（浏览器右上角工具→ 更多工具→ 开发者工具），火狐、edge等其他浏览器都有类似工具，可互联网搜索“浏览器名 + 开发者工具”。

2.1.1网络请求分析

打开方式：开发者工具→ 顶部网络（Network）面板→ 刷新网页（开始记录），网页地址需添加debug=true。

使用方法：F12-network

关键信息解读：

在分析仪表盘/电子表格等报表资源时，可重点关注：

1. 网络瓶颈：可通过关注XX.js/css等静态文件的下载速度，快速判断是否网络瓶颈。

2. 报表制作问题：可关注图片请求大小和请求数量，当使用太多url控件可能带来请求太多影响页面响应性能，对于制作过程使用太大背景图、上传太多图片也会影响整体的性能体验。

3. 取数相关请求性能：如V11/api/pages/beans/merge-aggregator请求，因这可能和数据库有关，需进一步用服务端分析工具确认。

4. 当发现非以上因素，点击工具栏下载录制结果上报问题分析。

5. 仪表盘网络分析思路请见如何分析仪表盘网络请求。

2.1.2页面性能分析（Performance/性能面板）

打开方式：开发者工具→ 点击 Performance/性能→ 点击圆形录制按钮 → 刷新页面 → 点击停止。

使用方法：Chrome浏览器渲染慢录制performance

关键指标解读：

注：此工具核心是录制之后下载，连同网络请求一起上报问题分析。

2.2Smartbi服务端性能分析工具

可以借助Smartbi主服务的性能/CPU采样工具，或多维执行引擎性能/CPU采样工具。

Smartbi主服务打开方式：Smartbi主服务系统右上角系统监控→ 性能→选择登录用户→开始→刷新页面或报表→暂停/下载。

使用方法：系统监控-性能（CPU采样）

多维执行引擎打开方式：Smartbi主服务系统右上角系统监控→左上角添加多维服务器→性能→选择登录用户→开始→刷新报表→暂停/下载。

使用方法：如何使用SmartbiOLAP监控器

关键信息解读：

注：此工具核心是录制之后下载，初步判断是否是数据库执行性能（包名带有数据库驱动特征，如mysql.xxx），如非数据库直接连同浏览端采集信息，直接上报问题分析。

2.3数据库端性能分析工具

主要指建立数据库连接和SQL执行性能。

SQL/MDX监控

打开方式：刷新报表→ Smartbi主服务系统右上角系统监控→ SQL/MDX监控→数据模型的原生SQL查询验证SQL性能→联系数据库运维，如发现是MDX也可进一步进入下面的MDX性能监控（可选，具体可看下面信息解读，信息不够才可进一步借助此工具）。

使用方法：系统监控-SQL/MDX监控

MDX性能监控

打开方式：刷新报表→Smartbi主服务系统右上角系统监控→ 左上角添加多维服务器→MDX查询监控→SQL监控→输入MDX编号查看执行SQL→数据模型的原生SQL验证SQL性能→联系数据库运维。

使用方法：如何使用SmartbiOLAP监控器

关键信息解读：

下图就是SQL/MDX监控界面，可以切换到当前登陆用户，查看当前登陆用户报表执行的SQL/MDX耗时。

如涉及MDX，就需切到对应MDX服务器，看对应的执行耗时，耗时长的mdx复制其编号，如“1881”。

再切到SQL监控，输入前面mdx编号，就可看执行的sql具体耗时。

三、排查流程

步骤1：网络问题：

1. 检查浏览器开发者工具Network面板中的js/css静态资源请求，如小文件都耗时很久大概率就是网络问题

2. 检查图片类请求大小及耗时，如请求太大，耗时太长确认是否报表上传的背景图等资源，需压缩图片

3. 检查请求数量是否超多，这可借助制作一个简单报表对比，请求数量多大概率报表制作不合理，如嵌套太多URL控件，每一个url控件都会带来重复框架脚本的执行

步骤2：服务端性能：

1. 检查Network面板中耗时最长的请求，如非静态资源，说明服务端存在性能问题

2. 借助数据库端性能分析，确认是否数据库端性能问题或拼写sql不合理，如是数据库问题联系数据库运维

3. 借助服务端性能分析工具，录制CPU采样上报问题查找优化空间

步骤3：页面执行性能问题：

1. 如网络中并无慢请求，请求也不算多，但是慢就可关注前端执行性能，如仪表盘中组件很多也会带来慢的可能（超200个组件需警惕）

2. 浏览器开发者工具Performance/性能执行情况，确认加载、脚本执行、渲染等耗时占比，上报问题分析

步骤4：提交有效信息上报问题：

1. 对开发团队说：“某页面加载要8s，没有慢请求，Performance中Scripting阶段耗时5秒”，而不是：“这个网页打开好慢，你们看看”

2. 附上网络请求录制结果、性能录制结果、cpu采样结果，具体附上哪些根据前面分析结果，如怕分析不准减少沟通时间，可将三个结果都附上

3. 对于是报表资源，建议附上报表资源定义文件，至少有个截图，主要辅助开发理解现场做的内容，对于报表的性能来说，制作的报表内容是个影响性能的重要变量

四、常见问题

1. 录制的网络请求/性能采样等内容，并非精准反应慢页面，含有很多其他无意义操作干扰问题分析
   1. 性能分析工具中，每一个的录制都建议仅包含慢操作的内容，如录制某个报表打开慢，那就仅录制这个报表打开过程，如是某个参数切换后慢，那就仅录制切换参数的操作
   2. 如经常收到说打开慢，结果看网络请求里面好多url，搞不清楚是一个报表嵌套了很多url控件，还是做了其他操作（有时是做了预览等其他操作），就需要重新录制
   3. cpu采样拿回，里面内容看不出慢，要么是没录制到慢操作，要么确实后端不慢之类
2. 移动端网络请求不知如何录制
   1. 如并非特定机型，特定app可重现的问题，可以用浏览器开发者工具，切换到移动设备                                                                                                                                                           
   2. 如必须用移动设备模拟，可借用charles等辅助录制，具体参考charles录制移动端请求。
3. 仪表盘资源常见报表制作带来性能问题
   1. 为了排版方便，使用过多url控件：每个url控件都带来了重复请求（有缓存时这块可忽略）和重复执行框架脚本的问题，如一个仪表盘打开，加载框架脚本要1s，多一个url就会多1s，尤其在首屏并且对性能需要极致体验的移动端，不建议用url控件，通过页签切换的第二屏之类使用没有问题。
   2. 过多组件：尤其含有指标卡之类的看板，一个指标看板能表达的内容，可能用了两三个组件表达，组件越多意味着浏览器端需要越多时间运行，通常如果取数不慢，但是仪表盘白屏时间较久可能就是此因素，方法就是尽可能减少组件，建议不要超过200个。
   3. 背景图太大：有些背景图加载都要2s，就会影响用户打开时的白屏体验，白屏越久，就会感觉越慢，建议要压缩图片大小
   4. 上传非常多碎片图片素材，占用浏览器请求，让整体性能体验降低，http1.1协议大部分浏览器同一个域名下是6~8个并发请求，这些碎片图片占用了请求就会造成其他请求排队等待，当然如果应用服务器部署http2，可忽略此问题，当确实需要较多图片素材，建议尽量合并为一张较大尺寸的含有图标素材的背景图。
   5. 仪表盘很大又有滚动条，未开启滚动加载，开启滚动加载就可按需初始化（仪表盘页面属性中设置开启滚动），就可提升用户首屏打开的体验
4. 电子表格报表制作带来性能问题
   1. 使用电子表格分组表，制作清单类报表，数据量很大，这类建议改为即席或透视，或用电子表格的清单表。因为分组表是要内存全部运算之后分页，面对大数据量场景不合适。