Semantic-model performance work should begin with one question: what is the user actually waiting for? A slow visual can be caused by DAX, model shape, relationship propagation, storage mode, source execution, Direct Lake fallback, capacity pressure, rendering, or several of those at once. For DP-600, optimization is not a bag of tricks; it is a process for locating the real constraint before trading one resource for another.
The broader business intelligence architecture matters because a semantic model sits in a chain. Data is prepared upstream, stored somewhere, shaped into facts and dimensions, queried under filter context, and served through a capacity. A local improvement can simply move work to another layer in the Fabric analytical stack. The only useful optimization is one that improves the end-to-end workload the organization cares about.
A practical mental model is therefore evidence → hypothesis → change → validation. Establish the baseline first. Identify the layer that dominates latency or resource use. Make one targeted change with an explicit trade-off. Re-run the same workload under representative data and concurrency. If the result is not materially better, reject the hypothesis rather than rationalizing the change.
Start from the slow interaction, not from the model diagram
Capture the exact page, visual, filter state, user persona, storage mode, and time of day associated with the complaint. A report that is slow only during refresh has a different problem from a DAX query that is always slow. A model that works for one administrator but slows under row-level security also requires a different investigation.
Define a target in user terms: first page should render within a few seconds, a drillthrough should complete before the user’s context is lost, or a refresh should finish before the reporting window opens. Without a target, tuning can continue indefinitely because every metric can always be improved a little.
User complaints should be grouped by shape before investigation begins. A single slow visual, an entire page that degrades, sporadic timeouts across many reports, and a refresh that misses its window all point toward different layers. Classification prevents the team from applying semantic-model tuning to a capacity incident or a source outage.
Separate query time from model and source behavior
Use Performance Analyzer and captured DAX queries to identify whether a visual spends time waiting on a semantic-model query or on rendering and other visual work. For Direct Lake models, examine whether queries remain in Direct Lake or fall back to DirectQuery where applicable. For DirectQuery models, capture the source query and source-side execution time.
The goal is to stop blaming the semantic model for work that actually belongs to the source, or vice versa. General logging and monitoring practice helps because the fastest investigations correlate evidence across layers rather than treating each product console as an independent truth.
Capture both query duration and the surrounding state. Capacity utilization, refresh activity, source latency, storage mode, and security persona can change the same DAX query’s behavior. A benchmark without environmental context is difficult to reproduce and easy to misinterpret.
For shared semantic models, preserve a handful of benchmark queries representing common and expensive workloads. They provide a stable reference when reports change over time and help distinguish a new report problem from a model regression.
Model size is a performance signal, not a verdict
Large models can perform well when columns compress efficiently and queries touch a narrow working set. Smaller models can perform poorly when they contain high-cardinality columns, ambiguous relationships, expensive measures, or remote queries. Model size is useful context, but it is not the bottleneck by itself.
Inspect unused columns, data types, cardinality, and model grain. Removing unnecessary detail can reduce memory and refresh cost, but it should follow analytical requirements. Do not remove a transaction identifier that supports audit drillthrough merely because a compression statistic looks attractive.
Column usage should be measured from actual reports and queries when possible. Removing a high-cardinality field that appears unused in one report can break Excel, XMLA, or another downstream consumer. Optimization decisions need dependency awareness as well as compression statistics.
Relationships can multiply work quietly
Bidirectional filters, many-to-many relationships, and large bridge tables can increase filter propagation cost and make query behavior harder to predict. The formula in a measure may be short while the model must traverse a complex graph to evaluate it.
Test whether the relationship design is genuinely required. Sometimes a cleaner star schema eliminates both performance and correctness problems. Other times a bridge is necessary and the optimization needs to happen elsewhere. The right question is not whether a pattern is ‘bad,’ but whether its cost is justified by the analytical behavior it enables.
Relationship testing should compare alternative designs with the same result set. A star-schema redesign can be powerful, but the team should demonstrate which joins and filter paths become cheaper rather than assuming the diagram’s cleanliness automatically produces speed.
DAX tuning needs an execution hypothesis
Iterators, context transitions, large virtual tables, repeated subexpressions, and broad filters can all contribute to expensive DAX. But replacing a function by reputation is not a method. Identify what the engine is doing more of than necessary, then test a rewrite that should reduce that work while preserving semantics.
Keep representative validation queries. A faster result is useless if totals, security-filtered views, or edge cases change. Enterprise models need optimization and regression protection together because a shared measure can affect many reports.
DAX investigation should keep cold-cache and warm-cache behavior separate. Some changes mostly affect repeated queries after data is cached, while first-use latency remains unchanged. If users frequently open reports with diverse filters, warm-cache improvements may not solve the dominant experience.
DAX rewrites should be reviewed for maintainability. An expression that saves a small amount of CPU but obscures business logic can create long-term cost in debugging and change risk. Performance evidence should justify added complexity rather than assuming shorter runtime is always the dominant objective.
Storage mode changes the bottleneck boundary
Import puts more responsibility on refresh and memory while usually giving interactive queries a highly optimized in-memory path. DirectQuery keeps data remote and makes source latency and concurrency central. Direct Lake can read Fabric Delta data directly, but capacity, physical table design, and fallback behavior where applicable still matter.
Storage mode should not be changed solely because one query is slow. A move can improve interactive latency while increasing refresh cost, source load, or operational complexity. Revisit the service objective before moving the architectural boundary.
Direct Lake analysis should inspect fallback behavior where relevant to the model architecture. A query that unexpectedly falls back can show a sharp latency change even when DAX itself is unchanged. Fixing the unsupported pattern or memory pressure may be more valuable than rewriting the measure.
Capacity pressure can imitate a bad model
A well-designed query can become slow on an overloaded capacity. Concurrency, background jobs, refreshes, notebooks, warehouses, and other Fabric workloads share capacity resources. If a performance incident correlates with sustained capacity pressure, rewriting one measure may not address the constraint.
Capacity evidence should be read with workload evidence. Which item consumed the compute? Was the operation interactive or background? Did the symptom begin after a workload change? This helps distinguish a model defect from a scheduling, sizing, or workload-isolation problem.
Capacity pressure can also be localized by workspace or time window. If semantic-model queries are healthy until a nightly notebook starts, workload isolation or schedule design may solve the problem. Scaling is justified only after the team understands whether the shared-resource conflict is expected and valuable.
Capacity analysis should include whether the model shares resources with unrelated workloads. If contention rather than model inefficiency is the dominant cause, workload isolation or scheduling can be safer than changing well-tested semantic logic.
Scale tests should reproduce the shape that matters
A query that is fast with one month selected may become expensive across five years. A report that is fast for one user may queue under a morning concurrency burst. A DirectQuery source that handles ten requests may fail at two hundred. Tuning needs the data distribution and user rhythm expected in production.
Include pathological but legitimate selections, not just the easiest demo state. Optimization is valuable when it changes the scaling curve, not merely when it wins one warm-cache benchmark.
Scale tests should record tail latency, not only averages. A median of two seconds can hide a small but painful population of twenty-second requests. Percentiles and slow-query samples reveal instability that users experience as unpredictability.
Validate the trade-off, not only the faster number
After a change, re-run the original workload and measure latency, resource consumption, refresh impact, memory, and source cost as appropriate. A 20 percent query improvement may not be worthwhile if it doubles refresh duration or makes maintenance substantially harder.
The final evidence should support a clear statement: this was the bottleneck, this change reduced it, this new cost was introduced, and this result remains better under realistic load. That is the difference between performance engineering and folklore.
Optimization should end with a rollback threshold. If the change increases refresh time beyond an agreed limit, raises model memory too much, or complicates maintenance without enough latency gain, revert it. Explicit success criteria keep tuning from becoming permanent complexity justified by a tiny benchmark win.
Document rejected tuning ideas alongside accepted ones. If a composite-model change was tested and rejected because it increased source load or broke a feature, recording that result prevents future teams from repeating the experiment without context.
