Forum Discussion

codybmb's avatar
codybmb
New Member
21 hours ago

Direct Lake Semantic Model Compute Usage Reduction

Hello,
I'm hoping to get some advice on compute reduction, when it comes to Direct Lake Semantic Models.
We've just given the end users access to the reports and the interactive compute usage is higher than we expected.

Someone on my team has suggested trying to replace some of the larger fact tables with aggregate tables, which is going to take so significant rework, as they're referenced in most of the reports. We would still need to keep the unaggregated tables in the model anyway because we need that level of detail for some of the reports.

I had 2 ideas on potential ways to reduce CU:
- Run a notebook after the model refreshes in the morning, to warm up some of the more commonly used tables. (I'm not sure if this will help with compute reduction or only improve performance.)
- Try optimizing some of the DAX measures in the reports. Some of them seem to be over-engineered and could definitely be written better.

For some additional context:
- We're on a F64 capacity
- We have built one central dimensional model, which service approximately 50 reports
- We have approximately 250-300 daily report users
- Auto refresh has been disabled (Refresh is triggered at the end of the ingestion pipeline in the early morning)

If anyone has any suggestions, it would be much appreciated. Hopefully I've given enough context.
Thanks!

capacities
one lake

1 Reply

  • MJParikh's avatar
    MJParikh
    Icon for Super User rankSuper User
    1 hour ago

    Thanks for the context. One question first: are you seeing throttling in the Capacity Metrics app, or only high interactive CU?

    Interactive CU is charged per query. Every visual sends a query for every user, so one slow measure on a busy page gets multiplied by 250+ users each morning. Query logic and report design drive most of the cost.

    On your ideas: cache warming improves first-open speed but does not reduce total CU. The load cost moves from the first user to the notebook. DAX optimization is the right call, since every fix repeats across every user.

    Steps:

    1. Open the Capacity Metrics app, filter to Interactive, and find the top items and timepoints by CU. A few pages usually drive most of the cost.
    2. Profile those pages with Performance analyzer and DAX Studio Server Timings. Rewrite measures with high formula engine time, such as FILTER over a full fact table or IF inside SUMX.
    3. Add Apply buttons under Options > Current file > Query reduction, and cut visuals per page.
    4. Confirm V-Order and run OPTIMIZE on large fact tables.
    5. Skip the model-wide aggregate swap. If reports use central measures, add aggregate logic inside two or three heavy measures only. Reports stay untouched.

    If you use Direct Lake on SQL endpoint, check for DirectQuery fallback in a DAX Studio trace. Fallback costs far more than in-memory queries.

    Next step: list your top five interactive items by CU from the last 14 days.

    References
    https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-how-it-works
    https://learn.microsoft.com/en-us/fabric/data-engineering/delta-optimization-and-v-order
    https://learn.microsoft.com/en-us/fabric/enterprise/metrics-app

    Thank you!
    Proud to be a Super User!
    🏷️ Need more help?
    ✅ Don’t forget to Accept as Solution if this guidance worked for you.
    ❤️Your Like motivates me to keep helping