Fabric Capacity Consumption

Hi Cookistador , I'm not an super expert on Power BI report optimization, I've seen very knowledgable people around here and I'm confident they will suggest on that, and I fully agree with the overview by Cookistador! 

I'm going to give a few pointers on "elaborate on the below point how we can identity which operation is occupying maximum capacity"  as I think based on your complex/high concurrent environment, you need a very detailed and strong monitoring framework... and yes, the obvious option would be using your monitoring workspace (read more on this https://learn.microsoft.com/en-us/fabric/admin/monitoring-workspace) but I think you should invest the time and implement  Fabric Unified Admin Monitoring (FUAM)! It is as of today, the best monitoring framework for Fabric! 

I know it seems you have bigger fish to fry (the performance issue you're facing) but in order to do a correct diagnostics, data and information about what running on your workspaces both on the background and interactive activities (kudos Cookistador ) is critical, so, I strongly suggest for you to implement FUAM ... is time & effort worth investing 😉  read more about it here  👉 https://github.com/GT-Analytics/fuam-basic

Best of lucks and I hope you find this information useful, if so, a kudos would be nice ... cheers 

Hi Nagarani , Thank you for reaching out to the Microsoft Community Forum.

The combination of dynamic RLS + many to many security + a 95M row fact table means every user generates a different DAX query plan. Power BI can’t reuse cache between users, so the engine must re-scan large parts of the fact table for every visual, for every user. On the deep-dive page alone, 19 visuals × 130 users become thousands of heavy queries hitting the capacity at the same time, which is why an F128 spikes to 158% even though a single user is fast.

You can see this directly in Fabric Capacity Metrics -> Interactive -> Query details. You’ll find a large number of ExecuteQueries with high CPU and very low cache reuse, especially when users open the deep-dive page or change slicers. Performance Analyzer or DAX Studio will show which visuals are expensive for one user, but Fabric metrics is what proves the concurrency + RLS problem.

Focus on the model, not just the capacity. Replace M2M RLS with a 1-to-many security bridge, pre-filter users to their allowed dimension keys and avoid bi-directional security paths. Pre-aggregate the 95M-row fact to the grain your visuals actually use and reduce the number of visuals and slicers on the heavy pages. Once cache can be shared again, the same F128 will handle far more users; without that, even larger capacities will keep hitting the same wall.