BI学习笔记

精品丨PowerBI负载测试和容量规划

2024-03-29  本文已影响0人  Fabric丨白茶

当选择Power BI作为业务报表平台时,如何判断许可证的选择是否符合业务需求,价格占了主导因素。
Power BI的定价是基于SKU和服务器内核决定的,但是很多IT的负责人都不确定自己公司业务具体需要多少。
不幸的是,Power BI的容量和预期使用量的比率很难进行量化的评估。

注:本文非原创,是搬运过来的,原文链接[1]在文章末尾。

例如:

一家公司可能有一个非常大的数据模型,需要占用大量的内存和CPU来进行长时间的刷新,高峰期有20个用户,每小时刷新一次,查询都非常简单,并且允许查询折叠。

另一家企业可能有6个较小的数据模型,高峰期有950个用户,每天刷新,数据模型的查询都非常非常复杂。这些相关元素都会影响后台资源的使用情况,使得预测总体资源并作为许可证选择的依据这件事变得几乎是不可能的。

值得庆幸的是,内存负载测试可以给我们提供一个良好的参照依据。
本文将介绍如何对你的内存进行负载测试、负载测试的规划要素以及如何理解负载测试的结果。

先决条件

搭建&测试

  1. 导航到负载测试工具的GitHub[4],下载包含PowerShell脚本的zip文件。负载测试工具有两个选项,默认测试 "最坏的情况",即所有用户同时登录,并不断点击过滤器,从而迫使Power BI忽略其缓存。
    现实加载测试工具[5]的操作类似于默认加载测试工具,但它测试的不是初始加载时间,而是最终用户可能会使用的可编程功能,如更改切片器、筛选器和浏览书签,并在操作之间留出一些 "思考时间"。
    在本演示中,我们将使用标准负载测试工具,以保持简单。
    有关使用实际负载测试工具的进一步说明,请参阅 ReadMe 文件。

    注意:
    此PowerShell脚本包含一个未签名的PowerShell脚本。必须首先使用Set-ExecutionPolicy Unrestricted命令才能允许运行未签名脚本。
    它还要求从此处安装[6] "MicrosoftPowerBIMgmt" Power BI PowerShell模块。

  1. 将文件解压缩到桌面(或虚拟机)上的文件夹中,然后导航到Initiate_Load.ps1文件。
    右键单击该文件,在PowerShell中运行。
  1. PowerShell脚本将引导你完成一些提示设置:
  1. 如果要测试数据集刷新是否会影响用户体验(反之亦然),请进入Power BI在线服务,并手动刷新正在进行负载测试报表的数据集。
    虽然负载测试工具适合测试交互操作,但是一些后台操作需要在工具外完成。
    有一些Rest Api[7]可以触发Power BI数据集刷新,本文不涉及这些。

  2. 如果浏览器窗口的数量超过了电脑的内存容量,则窗口会超时,需要单独刷新浏览器页面以使它们再次运行。

负载测试到现在已经完成!需要等待大约45分钟。然后手动刷新容量和指标报表的数据集。

容量规划注意事项

Power BI容量规划和管理是一项艰巨的任务。

微软建议根据Power BI项目(数据集、数据流等)的大小来设置容量大小,因为这个直接影响SKU内的操作速度(提前规划容量[8])。

这是一个很好的建议,但不幸的是,这种方法不适合数据总量小且交互频率非常高的项目。

例如:
假设有一个经过认证的数据集和八个使用该数据集的报表。
每个报表都有20-30人观看,因为现在是月底,所有的分析师、客户经理和高管都在用这些报表的截图准备他们的汇报。
这时候此数据集(以及容量)的负载就像有160-240个用户与数据集交互一样。
现在把它放大——如果有100个人在看每份报表。
针对此数据集/项目的使用会成倍增长,因此经过优化的认证数据集对CPU的压力要比只有一个报表的数据集大得多。
这就是为什么在评估最佳SKU/CPU的时候,必须同时考虑后台操作和交互操作的原因。

Power BI中的容量由以下几个变量决定:

值得庆幸的是,Gen2指标应用程序根据这些变量提供了对容量当前状态分析。

结果分析

Premium容量利用率和指标报表提供了前14天或28天的容量使用情况的可视化报表。
此报表与容量度量本身非常相似,可能非常复杂且难以理解。

微软已经提供了一些关于该报表内容的说明,不过回归到上面所做的负载测试结果相关。

在开始之前,请确保刷新了Premium容量利用率和指标报表的数据集(测试结束后需要等待45分钟,以确保测试结果数据进入到报表中)。

进入报表后,要将报表数据范围缩小到最新测试的日期,可以通过页面的过滤器窗格设置“所有页面过滤”,日期过滤到测试的日期。

如果进行了多轮测试,那么通过此报表可以了解每个测试节点的更多信息。

总览页面右上角的图表对于了解在测试过程中是否有测试导致CPU峰值超过了限制非常有效。

例如:
进了3次测试,但是只有一次导致CPU峰值达到了168%,要了解具体的细节,可以通过Power BI的钻取功能下钻到细节中去查看。

这是报表中我最喜欢的部分。在这个页面中,可以看到在过去24小时内,除了所有后台操作之外,每隔30秒内发生的交互操作的数量。

在评估可用容量负载时,了解当前SKU的限制非常重要。

在示例中,分配的SKU是A1,它允许30s的CPU容量,了解了这个之后,来看看611个交互操作造成了多少秒的CPU时间。

50.6秒,导致容量使用达到了169.98%。

因为使用了负载测试工具,所以所有这些交互的操作都代表Power BI用户。

但是在生产环境中,需要判断30s的CPU容量允许多少个用户与报表进行交互过滤。

值得庆幸的是,这种高强度的交互并没有影响报表的加载,也没有造成服务故障,不过如果想一直保持良好的运行状况,可以根据情况扩展容量。

在示例中,后台交互(刷新数据模型)在过去24小时内仅占容量的0.53%。

不过需要警惕的是,虽然CPU支持的秒数比交互操作要大得多,但是后台的一些操作也是包含在24小时内的框架下计算的。

如果一次测试多个数据集,建议按Artifact排序,然后按住shift键,且按CPU字段交叉排序。

这样,就可以判断一个数据集是否比另一个数据集消耗更多的资源(查看平均CPU秒数来判断)。

点击可视化视图右上角的三个点,可以将这些结果导出到excel或CSV中,以便进一步检查或将多个测试的结果堆叠起来并进行二次分析。

对于上面的示例,建议增加SKU以获得更多CPU,来容纳更多的用户,并保证用户可以进行大量的交互操作。

除此之外,还可以检查测试的数据模型,对接的数据源最好有折叠查询[9]和严谨的星型模型[10]来减轻CPU的压力。

引用链接

[1] 原文链接: https://dataonwheels.wordpress.com/2022/02/22/power-bi-embedded-stress-testing-capacity-planning/
[2] 利用率和指标报表: https://learn.microsoft.com/en-us/fabric/enterprise/metrics-app-install?tabs=1st
[3] 负载测试工具: https://github.com/microsoft/PowerBI-Tools-For-Capacities
[4] GitHub: https://github.com/microsoft/PowerBI-Tools-For-Capacities
[5] 测试工具: https://github.com/microsoft/PowerBI-Tools-For-Capacities/tree/master/RealisticLoadTestTool
[6] 此处安装: https://learn.microsoft.com/en-us/powershell/power-bi/overview?view=powerbi-ps
[7] Rest Api: https://learn.microsoft.com/en-us/rest/api/power-bi/datasets/refresh-dataset
[8] 提前规划容量: https://learn.microsoft.com/en-us/power-bi/enterprise/service-premium-capacity-manage
[9] 折叠查询: https://learn.microsoft.com/en-us/power-query/query-folding-basics
[10] 星型模型: https://learn.microsoft.com/en-us/power-bi/guidance/star-schema

上一篇 下一篇

猜你喜欢

热点阅读