Microsoft Fabric Community Conference 2025, March 31 - April 2, Las Vegas, Nevada. Use code MSCUST for a $150 discount.
Register nowThe Power BI DataViz World Championships are on! With four chances to enter, you could win a spot in the LIVE Grand Finale in Las Vegas. Show off your skills.
Hi,
Since yesterday, the service is very slow. A simple NestedJoin over a table that contains 9277 records with another table that has 17 000 records took over 20 minutes to get to save. I was afraid I might lose everything I did in case of a timeout or a communication problem.
I have a lot of NestedJoins to do and this is too lsow. It is putting a lot of pressure on our project.
Can someone please tell us what's happening and when will it be resolved?
Solved! Go to Solution.
Though I appreciate the tiem you spent gathering this information, I think everyone misses the key element of my initial request.
It begins with "Since yesterday..."
The same query was already fast before that specific day.
And it is fast again now.
I have got information that our On-Premise gateway was struggling to get bandwidth to our On-Premise data sources.
Somehow, even though I was not using our On-Premise gateway, I was still affected by the bandwidth limitations. IT got back to normal once our IT found the source and restored normal bandwidth.
But I've learned a lot from you guys, even though it did not help much.
But I'm still convinced that Microsoft has to do something about this crappy performance even when I have full bandwidth availability. I don't understand how they are doing things behind the curtains but something's not right because I can run the same steps in RStudio within seconds.
Thinking that publishing a dataset will resolve this performance caveat is just ignoring a problem that will cost more money in computing time and in bandwidth usage.
That being said, I'll close out this issue and we may discuss performance acceptance criterias in other threads... Thanks again for you time and consideration.
Hi @FireFighter1017 ,
Here are some suggestions for your reference:
1. Whether your data source supports query folding is also very important for performance and refresh speed. You can also use the query diagnostics tool to accurately check the cause of the slowdown.
https://docs.microsoft.com/en-us/power-query/recordingquerydiagnostics
https://docs.microsoft.com/en-us/power-query/power-query-folding
2. If the amount of data is too large, you can consider optimizing the datasource:
https://docs.microsoft.com/en-us/power-bi/guidance/power-bi-optimization
3. Optimize the URL of the merge operation:
https://community.powerbi.com/t5/Desktop/PowerQuery-Merge-Queries-HORRIBLE-performance/td-p/584532
Best Regards,
Liu Yang
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.
Though I appreciate the tiem you spent gathering this information, I think everyone misses the key element of my initial request.
It begins with "Since yesterday..."
The same query was already fast before that specific day.
And it is fast again now.
I have got information that our On-Premise gateway was struggling to get bandwidth to our On-Premise data sources.
Somehow, even though I was not using our On-Premise gateway, I was still affected by the bandwidth limitations. IT got back to normal once our IT found the source and restored normal bandwidth.
But I've learned a lot from you guys, even though it did not help much.
But I'm still convinced that Microsoft has to do something about this crappy performance even when I have full bandwidth availability. I don't understand how they are doing things behind the curtains but something's not right because I can run the same steps in RStudio within seconds.
Thinking that publishing a dataset will resolve this performance caveat is just ignoring a problem that will cost more money in computing time and in bandwidth usage.
That being said, I'll close out this issue and we may discuss performance acceptance criterias in other threads... Thanks again for you time and consideration.
hey,
have you tested the model on power BI desktop? if so evaluate the model using the performce tools, dax studio, etc to find where can be a problem with the model itself, also lots of relantionship depending on the cardianality will slow everything down this you can check over dax studio too,
also the licence model for your service its important, isnt the same procesing volumne that works your model on a free/pro/primiun licence, if the you using the first 2 it will also depend since its a shared power procesing not dedicated,
ho this helped if so give some kudos, for more tips you do will need to submit some example to look at your model and settings.
Proud to be a Super User!
DAX studio won't help since I'm talking about Power Query transformations. Not DAX Queries.
As for licensing, I'm already on a Premium license.
User | Count |
---|---|
47 | |
26 | |
21 | |
19 | |
18 |
User | Count |
---|---|
53 | |
47 | |
24 | |
20 | |
19 |