分享方式：

編頁報表容量規劃

  • 文章

適用範圍：Power BI 編頁報表 Power BI 服務 Power BI Desktop

了解如何規劃 Premium 容量，以最低成本獲得編頁報表的最佳效能。 如果要從其他商業智慧工具移轉至 Power BI，請考慮先閱讀下列文章，再決定要使用哪種容量。

產能規劃

計算所需的容量類型取決於多個因素，例如報表中的視覺效果數量、針對報表的查詢複雜度，以及資料來源或資料模型的品質。 在新增編頁報表之前，應考慮容量在尖峰期間的目前使用情況。

在開始規劃所需的容量之前，請檢閱容量和 SKU資料表，以查看每個容量所提供的資源。

當您規劃容量時，請考慮下列事項：

  • 報表設計的複雜性。 巢狀的 Tablix、多個子報表和多個資料列和資料行群組會新增設計的複雜性，並需要容量資源。

  • 報表擷取的資料量。 報表所需要的資料越多，需要從您的容量獲取的資源就越多。

  • 報表擷取資料的方式。 使用連接器、驅動程式或閘道時，資料擷取可能需要較長的時間、需要更多資源，因此成本會變得更昂貴。

  • 與讀取每個頁面、使用切換和在報表中搜尋相比，將大型報表匯出為 Excel 和 PDF 等格式需要更多的資源。

SKU 可以處理多少使用者？

為了測試不同容量的編頁報表，我們會針對不同的 SKU 大小執行三種不同類型的工作負載。 每個工作負載都由一個同時轉譯的單一報表 (大小不同) 組成。

  • 小型 – 從 Azure SQL 資料來源建置超過 100 列的資料彙總資料表。

  • 中型 – 從 Azure SQL 資料來源建置超過 100,000 列的資料彙總資料表。

  • 大型 - 從 Azure SQL 資料來源建置超過 250,000 列的資料彙總資料表。

我們對 Power BI Premium 的分析顯示，在任何指定時間 (包括每日尖峰時間) 的並行使用者數目往往不超過使用者總數的百分之五。

根據 5% 並行比率，下表描述了 SKU 在多載之前，可以處理的近似最大使用者數目。 當容量超載時，會對您的容量進行節流。 如需詳細資訊，請參閱如果我不自動調整，多載期間的流量會發生什麼情況？

工作負載 F64 或 P1 SKU F128 或 P2 SKU
小型 2,500 位使用者 5,000 位使用者
中 1,900 位使用者 3,800 位使用者
大型 1,300 位使用者 2,600 位使用者

考慮到資料表中的數字是指未執行其他作業的指定容量。 您的容量可能已將 CPU 資源用於下列作業：

  • 資料擷取和處理

  • 其他工作負載和背景作業

  • 複雜的資料群組和重塑

  • 資料篩選

並行要求數

容量上的每個工作負載 (包括編頁報表工作負載) 在任何指定時間最多會轉譯 500 個並行報表。 如果容量正在轉譯 100 個報表，而且有 200 個匯出編頁報表的要求，則還剩下 200 個並行報表轉譯要求。

若要避免壅塞，請提前規劃並行要求負載。 如果您超過並行要求限制，將遇到要求數太多 (429) 錯誤。

使用計量應用程式

使用Microsoft Fabric Capacity Metrics 應用程式，可以估計編頁報表對容量的影響。 應用程式會隨著時間測量 CPU 使用量，讓您了解容量的執行方式。

若要測試編頁報表，建議您使用專用的全新容量。 全新容量有助於使結果不會受到其他使用者和工作負載的影響。

根據目標測試案例 (例如平均或最大使用量驗證)，選取或建立代表預期資源消耗的報表，並將其上傳為測試建立的容量中的 Premium/Fabric 工作區。

執行報表數次，並使用計量應用程式取得執行報表所用的平均 CPU 秒數。 計算執行報表所需的時間時，請考慮下列事項：

  • 應用程式顯示的是彙總值，您可能需要將結果除以執行報表的次數。

  • 報表轉譯可能涉及多個 Power BI 項目和作業。 您可能需要加總 CPU 使用量。

  • 報表轉譯可能涉及多個 Power BI 項目和作業，因為轉譯可能需要很長的時間。 [時間點] 頁面中長時間執行的作業可以顯示為作業清單，持續時間不超過 30 秒。 您可能需要加總轉譯作業的 CPU 使用量。 依開始時間排序有助於顯示轉譯的完整歷程記錄。

計算報表轉譯量上限

使用此公式來計算容量在多載之前可處理的最大並行報表轉譯量。

$ \text {max concurrent report renders} = {\text {number of capacity SKU cores} \times {30} \over \text {your report's CPU processing time (in seconds)}} $

計算使用者數目上限

將估計的 5% 並行數用於取得使用者總數與並行轉譯上限之間的關聯性，可以得出 SKU 可以處理的使用者總數。

$ \text {max SKU users} = {\text {max concurrent report renders} \over 0.05} $

計算多個報表的容量資源

您可以使用擴充公式來估計不同報表使用情況所需的容量。

上傳具有每日轉譯不同次數的多個編頁報表，並使用計量應用程式取得每個報表的平均 CPU 處理時間。 每天所有報表轉譯的總和應等於 100%。 當您掌握了所有資訊時，請使用此公式。

$ \text {max concurrent report renders} = {\text {number of capacity SKU cores} \times {30} \over {\text {A renders} \times \text {A processing time}} + \text {B renders} \times \text {B processing time} + \text {...} + \text{N renders} \times \text{N processing time}}$

範例

本節包含兩個範例，一個用於一般計算，另一個用於進階計算。

一般計算

假設您在具有八個核心的 F64 或 P1 SKU 上執行編頁報表。 10 次執行的 CPU 使用量總計為 40 秒，因此每個報表的平均 CPU 時間為 4 秒。

$ 60 = {8 \times {30} \over 4} $

使用第二個公式時，最多可獲得 1,200 位使用者。

$ 1,200 = {60 \over 0.05} $

對於 F128 或 P2 SKU，可以將這些數位乘以 2，因為容量擁有兩倍的 CPU 核心數。

進階計算

假設您有三個編頁報表，每日轉譯百分比列於下表中。

報告 每天轉譯的報表數 CPU 處理時間 (以秒為單位)
A 60% 4
B 30% 10
C 10% 20

F64 或 P1 SKU 的公式為：

值 公式
並行報表轉譯上限 $ ~32.4 = {8 \times {30} \over 0.6 \times{4} + 0.3 \times{10} + 0.1 \times{20}} $
SKU 使用者總數 $ ~650 = {32.4 \over 0.05} $

相關內容