性能分析

1）依赖内置的「FineBI 直连性能分析插件」

插件默认不启动，需手动启动

插件版本跟随 JAR 自动更新

2）仅支持实时数据下的性能分析

1）功能不再由插件提供，直接合并至产品

2）支持实时数据和抽取数据下的性能分析

3）优化执行阶段的耗时计算逻辑

数据

「我的分析」主题中，数据编辑界面，支持进行「性能分析」

「我的分析」主题中，组件编辑界面，支持进行「性能分析」

「我的分析」主题中，仪表板编辑界面，支持进行「性能分析」

「我的分析」主题中，仪表板预览界面，支持进行「性能分析」

性能分析内容为数据时：一级资源名称为数据集名称

性能分析内容为仪表板时：一级资源名称为仪表板名称

性能分析内容为数据时：二级资源名称为数据集中分析步骤名称

性能分析内容为仪表板时：二级资源名称为仪表板中组件名称

查询的执行计划解析

查询内容为直连数据时：代表生成 SQL 的阶段

查询内容为抽取数据时：代表抽取引擎的查询描述生成的阶段

查询内容为直连数据时：代表直连数据库执行时间

查询内容为抽取数据时：代表抽取引擎计算时间

查询结果返回给FineBI的时间

若直连引擎自己计算，则没有该时间

所有FineBI代码的计算时间

例如树引擎分页计算，二次计算等

性能分析内容为数据时：一级资源名称为数据集名称

性能分析内容为仪表板时：一级资源名称为仪表板名称

性能分析内容为数据时：二级资源名称为数据集中分析步骤名称

性能分析内容为仪表板时：二级资源名称为仪表板中组件名称

1：分组表

2：交叉表

3：明细表

4：图表

5：自助数据集

6：筛选控件

7：文本组件

1）等待开始阶段

因为浏览器的限制导致查询之前需要排队

2）查询准备

• 执行计划构建：FineBI引擎在拿到查询请求时构建如何组织查询的阶段

• SQL 生成及 SQL 优化：对应的查询转换成 SQL 以及对 SQL 进行优化的阶段

3）SQL 执行

• 创建数据连接：执行前需要获取和数据库的连接

• SQL 执行：数据库查询执行的时间

4）数据传输

数据库返回的结果传给 BI 服务器花的时间

5）内存计算

直连引擎计算的时间

6）等待结束

等待结束阶段（把仪表的所有组件都打包成一个请求时会有该数据），最先出来的组件要等到最后出来的组件的等待时间

7）前端渲染

• 数据传输（BI 服务器-用户浏览器）：BI 服务器将数据传给用户浏览器的时间

• 前端渲染
  

创建数据连接阶段记录数据连接名

SQL 执行阶段记录执行的 SQL ，SQL 超过 3w 字符的，导出的文件会生成两个 sheet ，包含详细信息和超出 3w 字符的 SQL

如果有临时表注入逻辑，查询 SQL 前面会有，excel insert cost xxx | selcet * ....这样的标识符

抽取

直连

记录本次查询的所有执行阶段耗时总和

记录本次查询的开始和结束时间

记录所有查询的所有执行阶段耗时总和

记录所有查询的开始和结束时间

定义说明：

从用户点击查询到进入查询准备阶段的时间，因为浏览器的限制导致查询之前需要排队

一般6个浏览器发送请求未返回时，会阻塞第7个及之后浏览器的请求

计算逻辑：

6.0.16及之后：[(请求返回的时间点-开始发请求的时间点)-后端查询消耗的时间点]

6.0.15及之前：请求返回的响应中服务端开始时间StartTime（BI服务器时间）- 查询请求的开始时间（用户浏览器的时间）（由于浏览器和服务器时区/时间可能不一致，因此存在时间为负数的情况）

异常排查方向：

1）查询并发过高

2）超出浏览器并发限制

定义说明：

FineBI直连引擎在拿到查询请求时构建如何组织查询的阶段
自助数据集生成ETLFlow的阶段

计算逻辑：

Widget生成BICriteria或者HyperCriteria的过程

ETLContext生成ETLFlow的过程

异常排查方向：

数据集/模板/组件太复杂

定义说明：

对应的查询转换成 SQL 以及对 SQL 进行优化的阶段

计算逻辑：

SQL 的生成和优化的时间

定义说明：

SQL执行前，需要获取和数据库的连接

计算逻辑：

DataBaseSouceEngine中数据库连接创建的时间

定义说明：

数据库执行查询的时间或TCERID引擎执行时间

由于执行时间包括临时表的时间，因此SQL执行时间可能比日志中要长

SQL 执行阶段记录执行的 SQL ，SQL 超过 3w 字符的，导出的文件会生成两个 sheet ，包含详细信息和超出 3w 字符的 SQL

如果有临时表注入逻辑，查询 SQL 前面会有excel insert cost xxx | selcet * ....之类的标识符

计算逻辑：

DataBaseSouceEngine中数据库的查询时间

异常排查方向：

1）数据库性能问题

2）SQL语句需要优化

定义说明：

数据库的查询结果返回给FineBI服务器的时间，

计算逻辑：

数据库查询结果集传输到BI服务器的时长+数据压缩时长/数据模型生成时长

如果没有这两部分，时间为0是正常的

异常排查方向：

1）若数据库查询结果集传输到BI服务器的时长过大，请排查服务器网络问题

2）若数据模型构建耗时过大，请优化分析逻辑

定义说明：

直连引擎计算的时间，所有BI代码的计算时间

计算逻辑：

自助数据集无内存计算时间，仪表板中包含以下过程：

分组时间：postGroup time

排序计算时间：tree sort

分页计算时间：groupPage procedure time:

依据排序计算时间：treeSortGist

树过滤计算时间：groupTreeFilter

树构建时间：treeMaker time

异常排查方向：

查询返回的结果集过大，需要优化分析逻辑

定义说明：

FineBI服务器将数据传给用户浏览器的时间

计算逻辑：

后端结束的时间点-前端接收到数据的时间点

定义说明：

后端计算完毕之后，前端js计算、渲染和展示的时间之和

计算逻辑：

组件最终渲染出来的时间点-前端拿到数据的时间点

异常排查方向：

分页行数过大

原因分析：正在执行查询中，无法同时导出详细信息

解决方案：请耐心等待查询结束，即可导出详细信息

原因分析：

6.0.15及之前，查询等待时间=请求返回的响应中服务端开始时间StartTime（BI服务器时间）- 查询请求的开始时间（用户浏览器的时间）

由于浏览器和服务器时区/时间可能不一致，导致毫秒级的差异，因此存在时间为负数的情况

解决方案：请升级工程至6.0.16及以上版本，查询等待时间逻辑优化

原因分析：查询命中了缓存，没有从数据库全新取数

解决方案：可先修改单表的缓存策略，再进行性能分析

原因分析：

数据集使用临时表制作，性能分析时会计算临时表的执行时间，而后台日志中不计算此段时间，因此两者不一致

解决方案：正常情况，无需解决

原因分析：

一个组件可能触发了多个SQL，而多条SQL并不一定是依次执行的。

查询执行时间＝所有SQL执行时间总和

总查询时间中的查询执行时间=从第一条SQL执行开始，到最后一条SQL执行结束的时长

两者并不相等，因此总查询时间可能会小于分项耗时合计值

解决方案：无

一个组件可能触发了多个SQL

例如去重、中位数、fixed等操作，由于需要计算父节点的合计值，就需要发送多条SQL

解决方案：正常情况，无需解决