在使用系统过程中，出现仪表盘、电子表格等报表打开性能不如预期，此时就需要分析性能瓶颈，找出优化方案。
先看一个性能公式：报表性能=浏览器端执行性能 + 网络下载性能+ 服务端执行性能。
其中服务端执行性能 = Smartbi服务端执行性能 + 数据库执行性能。
在排查性能问题的过程中，我们通常会按照以下顺序进行：
网络性能排查→服务端性能排查→页面执行性能排查→提交有效信息问题上报
接下来将分别介绍如何通过性能分析工具对这些步骤进行排查，以系统地定位性能问题。
根据前面性能组成部分，每一块都需分析其性能瓶颈，主要借助到以下工具
浏览器开发者工具可帮助诊断问题出在服务端响应、网络传输还是网页本身代码效率上，并且都可下载录制结果，便于后续上报问题分析。如chrome开发者工具（浏览器右上角工具→ 更多工具→ 开发者工具），火狐、edge等其他浏览器都有类似工具，可互联网搜索“浏览器名 + 开发者工具”。
打开方式：开发者工具→ 顶部网络（Network）面板→ 刷新网页（开始记录），网页地址需添加debug=true。
使用方法：F12-network
关键信息解读：
界面元素 | 通俗解释 | 运维关注点 |
Status（状态码） | 类似快递单的“物流状态”： - 200：成功签收（正常） - 404：包裹丢了（资源不存在） - 500：仓库爆仓（服务器错误） | 红色状态码（4xx/5xx）：服务器或配置问题 |
Time（加载时间） | 包裹从下单到送达的时间： - 超过1秒的请求需警惕 | 长时间请求：可能是服务器慢或网络拥堵 |
Size（资源大小） | 包裹的重量： - 图片/视频过大（>1MB）可能拖慢页面 | 大文件：建议压缩或使用CDN加速，对于仪表盘等资源，用户可上传背景图等资源太大都会影响性能 |
Waterfall（瀑布流） | 每个包裹的运输轨迹： 查看“排队等待”“下载耗时”阶段 | 长时间等待（浅色部分）：服务器响应慢 |
在分析仪表盘/电子表格等报表资源时，可重点关注：
网络瓶颈：可通过关注XX.js/css等静态文件的下载速度，快速判断是否网络瓶颈。
报表制作问题：可关注图片请求大小和请求数量，当使用太多url控件可能带来请求太多影响页面响应性能，对于制作过程使用太大背景图、上传太多图片也会影响整体的性能体验。
取数相关请求性能：如V11/api/pages/beans/merge-aggregator请求，因这可能和数据库有关，需进一步用服务端分析工具确认。
当发现非以上因素，点击工具栏
下载录制结果上报问题分析。
仪表盘网络分析思路请见如何分析仪表盘网络请求。
打开方式：开发者工具→ 点击 Performance/性能→ 点击圆形录制按钮 → 刷新页面 → 点击停止。
使用方法：Chrome浏览器渲染慢录制performance
关键指标解读：
指标 | 通俗解释 | 运维关注点 |
Loading（加载） | 从下载网页到显示骨架的时间 | 时间过长可能是网络慢或HTML/CSS文件太大，或报表嵌套URL带来请求过多 |
Scripting（脚本） | 页面代码执行耗时（如按钮点击响应） | 长时间“脚本”块 → 前端代码效率低 |
Rendering（渲染） | 浏览器绘制页面元素的时间 | 时间过长可能是复杂动画或大量DOM操作 |
黄色三角警告 | 浏览器提示的“高负载任务” | 点击查看详情 → 记录任务名称反馈开发团队 |
注：此工具核心是录制之后下载，连同网络请求一起上报问题分析。
可以借助Smartbi主服务的性能/CPU采样工具，或多维执行引擎性能/CPU采样工具。
Smartbi主服务打开方式：Smartbi主服务系统右上角系统监控→ 性能→选择登录用户→开始→刷新页面或报表→暂停/下载。
使用方法：系统监控-性能（CPU采样）
多维执行引擎打开方式：Smartbi主服务系统右上角系统监控→左上角添加多维服务器→性能→选择登录用户→开始→刷新报表→暂停/下载。
使用方法：如何使用SmartbiOLAP监控器
关键信息解读：
界面元素 | 通俗解释 | 运维关注点 |
CPU时间占比 | 整个采样是个典型的调用栈树结构，A函数调用了B和C函数，B和C就是A的子节点，展开A可以分别看到B和C分别占总时间的占比 | 关注占比大的层层展开， |
耗时 | 此方法实际耗时，他的耗时可能是子函数带来的 | 关注执行时间长的层层展开 |
包名和方法名 | 图中每一行都含有类似：smartbix.page.executor2.chart.EChartsAbstractExecutor.getChartData，实际指包名和方法名，可以定位到具体代码 | 通常如果是数据库性能问题，展开到后面可以看到驱动的方法，包名带有数据库驱动特征，如mysql，如果是smartbi问题的一般都是smartbi或smartbix打头。 |
注：此工具核心是录制之后下载，初步判断是否是数据库执行性能（包名带有数据库驱动特征，如mysql.xxx），如非数据库直接连同浏览端采集信息，直接上报问题分析。
主要指建立数据库连接和SQL执行性能。
SQL/MDX监控
打开方式：刷新报表→ Smartbi主服务系统右上角系统监控→ SQL/MDX监控→数据模型的原生SQL查询验证SQL性能→联系数据库运维，如发现是MDX也可进一步进入下面的MDX性能监控（可选，具体可看下面信息解读，信息不够才可进一步借助此工具）。
使用方法：系统监控-SQL/MDX监控
MDX性能监控
打开方式：刷新报表→Smartbi主服务系统右上角系统监控→ 左上角添加多维服务器→MDX查询监控→SQL监控→输入MDX编号查看执行SQL→数据模型的原生SQL验证SQL性能→联系数据库运维。
使用方法：如何使用SmartbiOLAP监控器
关键信息解读：
界面元素 | 通俗解释 | 运维关注点 |
数据源 | 代表最终数据输出由哪里出 SQL引擎V2.0：代表此查询路径命中SQL引擎V2.0 SmartbiCache：代表直接查询高速缓存库 mondrian(SmartbiCache或其他数据源)：代表命中多维引擎 其他直连数据源：代表直接查询原业务库 | 如需进一步确认业务库/高速缓存库执行性能，不同数据源跟踪路径有些差异，其中SQL引擎V2.0和mondrian中间还有计算过程，耗时不仅仅是数据库执行性能 |
SQL/MDX | 可以查看详细的SQL或MDX耗时，如数据源是SQL引擎V2.0，点进去可以通过dsId属性找到原业务库/高速缓存库执行sql及性能。 如数据源是mondrian，可以批量看到此条MDX实际运行了哪些SQL，每条SQL的耗时。 其他数据源是可直接看到对应执行SQL | 关注执行时间长的SQL，可复制此SQL出来新建原生SQL查询验证性能，注意原生SQL要选对业务库，如是抽取需选择高速缓存库。 联系数据库运维：如验证发现SQL并无可优化空间，可联系数据库运维确认，如不确信可上报问题到开发分析 |
耗时 | 执行耗时，单位ms，1000ms代表1s | 关注耗时长的进一步分析 |
下图就是SQL/MDX监控界面，可以切换到当前登陆用户，查看当前登陆用户报表执行的SQL/MDX耗时。
如涉及MDX，就需切到对应MDX服务器，看对应的执行耗时，耗时长的mdx复制其编号，如“1881”。
再切到SQL监控，输入前面mdx编号，就可看执行的sql具体耗时。
步骤1：网络问题：
检查浏览器开发者工具Network面板中的js/css静态资源请求，如小文件都耗时很久大概率就是网络问题
检查图片类请求大小及耗时，如请求太大，耗时太长确认是否报表上传的背景图等资源，需压缩图片
检查请求数量是否超多，这可借助制作一个简单报表对比，请求数量多大概率报表制作不合理，如嵌套太多URL控件，每一个url控件都会带来重复框架脚本的执行
步骤2：服务端性能：
检查Network面板中耗时最长的请求，如非静态资源，说明服务端存在性能问题
借助数据库端性能分析，确认是否数据库端性能问题或拼写sql不合理，如是数据库问题联系数据库运维
借助服务端性能分析工具，录制CPU采样上报问题查找优化空间
步骤3：页面执行性能问题：
如网络中并无慢请求，请求也不算多，但是慢就可关注前端执行性能，如仪表盘中组件很多也会带来慢的可能（超200个组件需警惕）
浏览器开发者工具Performance/性能执行情况，确认加载、脚本执行、渲染等耗时占比，上报问题分析
步骤4：提交有效信息上报问题：
对开发团队说：“某页面加载要8s，没有慢请求，Performance中Scripting阶段耗时5秒”，而不是：“这个网页打开好慢，你们看看”
附上网络请求录制结果、性能录制结果、cpu采样结果，具体附上哪些根据前面分析结果，如怕分析不准减少沟通时间，可将三个结果都附上
对于是报表资源，建议附上报表资源定义文件，至少有个截图，主要辅助开发理解现场做的内容，对于报表的性能来说，制作的报表内容是个影响性能的重要变量
