Regulate F64 (reserved) capacity peaks from single operations

[KaySunset]

Hi all,

we have a F64 reserved Fabric Capacity in place and are currently changing all data connections in Power BI from Azure Analysis Service Cubes to Semantic Models. It's all going well most of the time, but we're experiencing reoccuring capacity peaks caused by only one or two interactive operations (see example in screenshot from Fabric Capacity Metrics App).

I am aware that we should check those semantic models and optimize them - but that'll take a while

In the meantime, I'd like to somehow regulate those peaks. In a best case scenario, I would want to tell Fabric that it should cancel any operation that needs more than 20 % of all of the capacity. Unfortunately there does not seem to be a setting like that. Is there anything similar or any workaround, that we could use, to achieve this goal? Any other tips to manage those peaks?

Thanks in advance,

Kathrin

[v-sgandrathi]

Hi @KaySunset,

Glad to hear the performance has improved and that you’ve pinpointed the main source of high usage. Continue observing the capacity trends and refine the model where necessary. Adjusting resource thresholds and optimizing key operations should help maintain stable performance going forward.

Thank you.

[KaySunset]

Thanks everyone for your prompt responses! I have & will be implementing all suggestions. Improving our models will not be avoidable, but it has gotten a little better.

By the way, we are now pretty sure that one (quite large) composite model is the main source of CU usage, so we know where to start 😉

[v-sgandrathi]

Hi @KaySunset,

Just wanted to follow up and confirm that everything has been going well on this. Please let me know if there’s anything from our end.
Please feel free to reach out Microsoft fabric community forum.

Thank you.

[KaySunset]

Hi @lbendlin, @tayloramy , @v-sgandrathi , @AntoineW ,

thank you so much for your detailed answers and suggestions! I'll definitely try those things out (and looking forward to the upcoming previews!)

I do have a follow-up question regarding the Query Caching suggestion from @AntoineW : Our main problem are "XMLA Read Operations" (mostly Excel Files that our users (unfortunately) indefinitely use). You can clearly see it in below screenshot as well.

As far as I understand Query Caching, this will not really help with those operations - or will it (and if yes, how)? 

My guess is (after your replies) that Surge Protection will be a stronger solution for these operations?

Thanks again for helping me understand 🙂

BR,
Kathrin

[tayloramy]

Hi @KaySunset, 

Based on the documentation: Query caching in Power BI Premium - Power BI | Microsoft Learn

The caching is performed the first time a user opens the report. The service only does query caching for the initial page that they land on.

THis makes me think that the XMLA endpoint bypasses caching alltogether. 

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.

[lbendlin]

We have switched off Query Caching.  It has provided no measurable benefits in our usage scenario- users' queries are just different enough to never be covered by the cache.

Your mileage may vary - go measure with and without.

[v-sgandrathi]

Hi @KaySunset,

The information provided by @AntoineW @lbendlin and @tayloramy  is accurate.
Currently, Fabric does not have a direct feature to stop queries that go over a certain capacity limit. The main approaches are to enable Surge Protection and to manage workloads between background and interactive tasks.

You can also monitor your capacity using the Fabric Capacity Metrics app to spot recurring heavy operations or models that cause usage spikes. With this data, you may choose to schedule refreshes during off-peak times or move certain models to a separate capacity.

Looking ahead, the upcoming capacity management preview will likely offer improved workload balancing and throttling options.

Thank you.

[lbendlin]

You will need to ask yourself what is more important to you - background operations or interactive operations.

Keep in mind that you can easily saturate your capacity with background operations, leaving no room whatsoever for interactive, and basically wasting your resources because no user can see the refreshed data.

Therefore your correct decision has to be to prioritize interactive operations.  This means that you MUST set up Surge Protection, and set it at a low level.  We set it to 35% on our reserved capacities, which will result in a roughly 50/50 balanced resource allocation between refreshes and interactive queries.

[tayloramy]

Hi @KaySunset, 

Right now there is no way to kill operations that use more than X% of the capacity. 

What @lbendlin is saying is correct, you need to balance background and interactive operations. 

What my org does for one really large project is we have one capacity specifically for background operations and one for interactive so there is no chance that background operations will prevent users from accessing the reporting. 

Surge protection also works well. 

I happen to know a little bit about this upcoming preview (And I'm super excited for this to become public preview so I can actually talk about how cool it is!): 

and once this comes out, you will be able to do what you are trying with some thinking and some math to apply smoothing operations. 

Keep an eye on the roadmap and watch out for the announcement for this preview. 

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.

[AntoineW · Accepted solution]

Hello @KaySunset,

Fabric doesn't have a direct control like cancel a query above 20% of capacity.

However, there is several ways to manage capacity peaks : 

1) Enable Surge Protection 

Fabric provides a feature, which automatically pauses or cancels background operations when capacity load becomes too high.

• Go to Admin portal → Capacity settings → Select the capacity > Expand Surge protection

• Define thresholds for background operations (refreshes, dataset queries, dataflows, etc.).

• This helps prevent capacity overloads and keeps the environment responsive for interactive users.

Docs : https://learn.microsoft.com/en-us/fabric/enterprise/surge-protection

2) Manage large model semantic 

If one or two models are consistently responsible for spikes:

• Consider isolating them in a separate Fabric capacity (PAYG) or smaller reserved capacity (F64 → F4 or F8) if you only need them occasionally.

• You can start and stop PAYG capacities based on usage patterns (for example, every Tuesday during heavy refresh periods).

Docs : https://learn.microsoft.com/en-us/fabric/admin/capacity-settings?tabs=power-bi-premium

3) Optimize semantic models and queries

While it takes time, optimization is the only way to truly prevent sustained peaks:

• Simplify your DAX measures (avoid unnecessary CALCULATE and FILTER nesting).

• Reduce visuals per page — each visual triggers multiple queries.

• Use TOPN or aggregation tables for large matrix visuals.

• Apply incremental refresh and hybrid tables where applicable.

• Enable query caching in the semantic model settings if interactive users are repeating queries.

Docs : https://learn.microsoft.com/en-us/power-bi/guidance/power-bi-optimization

Keep tracking the patterns with Microsoft Capacity App Metrics.

Hope it can help you !

Best regards,

Antoine