Skip to main content

Optimising the Measures with DAX Studio

Another week another blog!! This week we will be focusing on the optimising the bad performing measures and how to tackle the measures generating Call back ID. Before starting, this blog is intended for Users who are a bit familiar with DAX Studio if not then you can do a quick read on our most read blog on our website (link).

Performance of report is a great factor in improving in the user experience and to check how well your visuals and DAX formulas are performing you can utilise the benefits of Performance Analyser. In my experience Performance analyser along with the DAX Studio is a match made in heaven. You can copy the query from Performance analyser and evaluate in DAX Studio. To know more about how performance analyser works do visit this interesting article (link).

Let's get our hands dirty and see how you can evaluate your DAX formulas. To do so I have created a basic DAX with help of Filter function 


Now, we have included this measure in a table along with the year coming from date table. Also, we have started recording with the help of Performance Analyser. Since our table is taking the most time to render let's evaluate the query running behind our DAX.


To do so you can copy query and go to DAX Studio with the connection to the same PBIX. Once you paste the copied query enable the server timings and query plan from top.


Now run the copied query and go to the server timings. What the heck is going on here? FE? SE? If you are not a fan of acronyms like me then FE stands for Formula engine while the SE stands for Storage Engine.


What does the FE and SE do? Here I would like to quote Data Mozart aka Nikola. Here is the link to the detailed article focusing on the concepts of SE and FE.


When you send the query to get data for your Power BI report, here is what happens:

  • Formula Engine (FE) accepts the request, process it, generates the query plan and finally executes it
  • Storage Engine (SE) pulls the data out of Tabular model to satisfy the request issued within the query generated by the Formula Engine
In simpler language FE act as a first layer and execute the DAX query as a rule of thumb do keep an eye on the number of queries generated in both Formula engine (FE) and Storage engine (SE). In this case, we have 3 queries running in background for this DAX. You can check the background query by clicking on every query. Now, let's optimise this by removing the Filter function in the DAX and repeat the same exercise. 

With a slight change in the DAX we have reduced the number of background queries also we have reduced the total duration from 17ms to 7ms. What has changed in the DAX?

Sales 100 filter = Calculate (Sum(Sales), 'Sales' > 100)

Isn't this amazing? Let's take it to the next level. On the journey of optimising the DAX you may encounter the concepts of Call Back ID. What is that? SE provides a data cache to FE but there are specific cases where the SE is unable to identify the DAX expression and ask the Call back ID to FE. 

Rule of thumb here states that try to get rid off the call back data ID because ultimately it slows down the performance of your DAX. The most common question here will be what are those DAX then can create Call back data ID. 

Perfect example for this will be use of IF function along with the iterators such as SUMX, AVGX and many more functions with X as a suffix to them. We have a created a measure with the same and we will see how call back data IDs are generated with just 3-4 lines of measures.


Once we have copied the query with the help of Performance analyser we will check the server timings and query plans running in background. 

To identify the queries that are generating the call back data ID once you check all the queries the one having the call back data ID it should be highlighted like mentioned in the image above. Also, note the total duration and the number of queries running in the background.

To improve this and as a part of best practices in optimising the DAX try not to combine the IF and iterator functions together instead use variables which can the eliminate the call back data ID. 



"All our articles are intended to address all the frequently asked questions related to a topic. Do leave a comment if it answers any of your question. "


Thanks for Reading Let's connect on LinkedIn. For more such blogs and pro tips do follow us





Comments

Post a Comment

Popular posts from this blog

Identify and Delete Unused Columns & Measures

Heavy dashboards and a bad data model is a nightmare for every BI Developer. Heavy dashboards can be slow due to multiple reasons. It is always advised to stick with best practices. Are you still figuring out about those best practices then you should definitely have a quick read on Best Practice Analyser ( link ). One of the most common issues with slow dashboards is unused columns and unused measures.  It is very normal to load some extra columns and create some test measures in your dashboard but as a part of cleanup process those unused columns and unused measures should be removed. Why we are removing them? Because if you keep them then ultimately it will increase the size of your data model which is not a good practice.  How to identify the culprits (unused columns and unused measures)? In today's blog we will provide you with 2 most common external tools which will help you in identifying the culprits. More external tools😒. Who's going to pay for this? To your surprise...

Best Practice Analyser (BPA) Guide

Do you want to save tons of efforts to check if your data model and PBIX file follows the standard best practices and norms? Then this blog is for you. If you are a follower of our channel we already deep dive into the importance of the DAX Studio as an external tool. If you are a beginner I would highly recommend to visit this blog . In today's blog we will check how Tabular Editor can help to optimize the data model.  Best Practice Analyser allows to define or import best practices. It will make sure that we do not violate the best practices while developing a dashboard. Isn't it exciting!! Before we start make sure you already have Tabular Editor version 2.24.1 installed on your system. To install it do visit this link and select the link for windows installer. Once Tabular Editor is installed it will reflect in your PBIX file under external tool. Also, we need to define the standard rules. To do so in your advanced scripting or C# script copy this and save it via Ctrl+S. An...

Everything about Paginated Reports

We know all the multitudes of Power BI and how it evolved over the years but have you ever thought what if you do not require all those fancy visuals and features but you need a flat table fitting in a single page and can go on for more than 100s of pages. If you are looking for something like this then Paginated Reports is the answer for you. In today's blog we will pen down everything you need to know about Paginated Reports. To know more about the Paginated Reports do read this interesting article from Microsoft. Before we start you will require - Report Builder (external tool but a FREE one) and Power BI Pro license along with the contributor rights to publish the paginated reports to different workspaces. Also, we will be working with Sample Superstore dataset. We are aiming to create a paginated report which will look something like this. Let's get started then, make sure you have published your dashboard in a workspace. For this demo, we have published the dashboard to...