Share via

分页报表容量计划

  • 项目

适用范围： Power BI Report 分页报表 Power BI 服务 Power BI Desktop

了解如何规划高级容量，以最低成本获得分页报表的最佳性能。 如果要从其他商业智能工具迁移到 Power BI，请考虑先阅读下列文章，再决定使用哪种容量。

容量计划

计算所需的容量类型取决于多个因素，例如报表中的视觉对象数量、针对报表的查询的复杂性以及数据源或数据模型的质量。 在向容量添加分页报表之前，还应考虑容量在高峰时段的当前使用情况。

在开始规划所需的容量之前，请查看容量和 SKU 表，了解每个容量提供了哪些资源。

规划容量时，请考虑以下事项：

  • 报表设计的复杂性。 嵌套的 Tablix、多个子报表以及多个行和列组增加了设计的复杂性，并需要容量资源。

  • 报表检索的数据量。 报表需要的数据越多，需要从你的容量中获取的资源就越多。

  • 报表检索数据的方式。 使用连接器、驱动程序或网关时，数据检索可能需要更长的时间、更多的资源，因此成本更高。

  • 与读取每个页面、使用切换开关和在报表中搜索相比，将大型报表导出为 Excel 和 PDF 等格式需要更多的资源。

SKU 可以处理多少用户？

为了测试不同容量的分页报表，我们针对不同的 SKU 大小执行了三种不同类型的工作负载。 每个工作负载由一个并发呈现的单一报表（大小不等）组成。

  • 小型 - 从 Azure SQL 数据源生成超过 100 行的数据聚合表。

  • 中型 - 从 Azure SQL 数据源生成超过 100,000 行的数据聚合表。

  • 大型 - 从 Azure SQL 数据源生成超过 250,000 行的数据聚合表。

我们对 Power BI Premium 的分析表明，在任何给定时间（包括每日高峰时间）的并发用户数往往不超过总用户群的 5%。

基于 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} $

相关内容