本文介绍用于计算 Microsoft Fabric 中的消耗的某些计算。 利用本文更好地了解 Microsoft Fabric 容量指标应用中显示的信息。
消耗分析
重载容量指计算能力达到 100% 以上的容量。 容量处于重载状态时时，会开始限制。 限制视觉对象有助于了解在给定时间点消耗占 Fabric 限制的百分比。 限制会一直持续，直到容量使用量低于 100%。 限制视觉对象有三个选项卡，每个选项卡显示有关不同限制类型的信息，这具体取决于不同的时间窗口。
| Tab | 阈值限制 | 容量达到 100% 时会发生什么情况？ | 容量需要多少时间才能恢复至 100%？ |
|---|---|---|---|
| 交互式延迟 | 10 分钟 | 对交互式请求应用 20 秒的限制 | 应用延迟后，新的交互式请求和后台请求将继续累积将来的计算使用量 |
| 交互式拒绝 | 60 分钟 | 交互式请求遭到拒绝，用户会在 UI 中看到错误 | 后台请求继续累积将来的计算使用量 |
| 后台拒绝 | 24 小时 | 所有请求均遭到拒绝，包括后台请求和交互式请求 | 空值 |
如果将来的计算使用量低于 100%，则接受其他请求。 这些请求可能会导致容量的使用量再次超过 100%。 此情况可能会视为单个连续限制事件，而实际上它是两个连续限制事件。
后台拒绝
由于后台拒绝阈值为 24 小时，因此高百分比限制数字表示过度使用每日（24 小时）容量资源。 后台拒绝高于 100% 时，将拒绝所有请求。 容量使用量低于 100% 后，将停止拒绝。 例如，后台拒绝 250% 意味着使用了 2.5 倍的 SKU 级别的每日容量资源量。
注意
后台作业不受限制，可以延长交互式拒绝停止所需的时间。
交互式延迟和交互式拒绝
查看这些视觉对象时，只会看到在特定时间点影响容量的内容。 这些视觉对象包括平滑到当前评估窗口的使用量。 之后的时间点可能包括不影响此时间点的其他平滑使用量。 后台平滑消耗可能会降低将来时间点中交互式请求可用的使用量。
交互式延迟 – 250% 的交互式延迟意味着 Fabric 正尝试在未来 10 分钟内适应 25 分钟的消耗。
交互式拒绝 – 250% 的交互式拒绝意味着 Fabric 正尝试在未来 60 分钟内适应 2.5 小时的消耗。
计算从限制中恢复的时间
使用量超过 100% 时，需要等待容量把将来的使用量降至 100% 以下。 可以使用以下公式估算降至 100% 以下需要多长时间，前提是不使用额外的计算。
$$ \text{minimum time to recover from throttling} = \frac{\text{% rejection type } – \text{ }100}{100}\times{\text{period duration}} $$
交互式拒绝和交互式延迟可能需要超过窗口持续时间的 1.5 倍才能停止限制。 新请求可能会向容量添加更多的结转使用量，使得容量使用量达到 100% 所需的时间比 60 分钟或 10 分钟的时间窗口更长。
后台拒绝计算示例
使用量达到 250% 时，将拒绝接下来 36 小时内的所有请求。
$$ \frac{250-100}{100}\times{24 \text{ hours} = 36 \text{ hours}} $$
容量使用量至少需要 1.5 天才能达到 100%。 不会拒绝后台作业，可以延长停止交互式拒绝所需的时间。
交互式拒绝计算示例
如果使用量达到 250%，至少在接下来的 90 分钟内只会拒绝交互式请求。
$$ \frac{250-100}{100}\times{60 \text{ minutes} = 90 \text{ minutes}} $$
容量使用量至少需要 1.5 小时才能降至 100% 以下。 但是，由于后台作业的未来消耗超过 10 分钟和 60 分钟的时间窗口，可能会影响容量，此事件的持续时间可能更长。
交互式延迟计算示例
当使用量达到 250% 时，交互式请求将在未来 15 分钟内延迟。
$$ \frac{250-100}{100}\times{10 \text{ minutes} = 15 \text{ minutes}} $$
容量使用量至少需要 15 分钟才能降至 100% 以下。 但是，由于后台作业的未来消耗超过 10 分钟和 60 分钟的时间窗口，会影响容量，此事件的持续时间可能更长。
性能增量
按项目和操作显示的矩阵表使用不同颜色来帮助了解 Fabric 项在组织中的表现。
无颜色 - 高于 -10 的值
橙色 - 介于 -10 和 -25 之间的值
红色 - 小于 -25 的值
若要创建性能增量，Microsoft Fabric 会计算完成时间不到 200 毫秒的所有快速操作的每小时平均值。 每小时值用作过去 7 天（168 小时）的慢速移动平均值。 然后，将慢速移动平均值与最近数据点和 7 天前的数据点之间的平均值进行比较。 性能增量表示这两个平均值之间的差异。
可使用性能增量值来评估你的项目的平均性能在过去一周内是改进了还是变差了。 值越高，性能可能越好。 接近零的值表示变化不大，负值表示项目的平均性能在过去一周内变差。
按性能增量列对矩阵进行排序有助于识别性能变化最大的语义模型。 在调查过程中，请不要忘记考虑 CU 和用户数量。 对于 CU 利用率较高的 Microsoft Fabric 项目，性能增量值是一个很好的指标，因为这些项目被大量使用或运行许多操作。 但 CU 活动很少的小型语义模型可能无法反映真实情况，因为它们很容易显示较大的正值或负值。