效能分析

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 * ....這樣的識別符號

1：SQL 引擎

2：csv 引擎（代表Excel資料集和伺服器資料集）

3：記憶體引擎

記錄本次查詢的所有執行階段耗時總和

記錄本次查詢的開始和結束時間

記錄所有查詢的所有執行階段耗時總和

記錄所有查詢的開始和結束時間

定義說明：

從使用者點選查詢到進入查詢準備階段的時間，因為瀏覽器的限制導致查詢之前需要佇列

一般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

解決方案：正常情況，無需解決