Paginated Reports Rendering Extremely Slow

Paginated reports are INSAINELY slow to the point of actually not being a useable service.  I've been writing SSRS reports for over 10 years and power bi premium in its current state is deplorable & unusable!!

I'm rasing a ticket because of this stupidity.  I have a date parameter that defaults to today (yes no database is needed for that) which I've had to get rid of because the report sits there for 10 mins and doesnt even load this.

My advice is dont use premium, stand up an SQL VM and use SSRS from there.

MICROSOFT ARE YOU LISTENING, THIS SERVICE IS GARBAGE!!

Most of this content would apply to Paginated PBI reports. https://www.mssqltips.com/sqlservertip/3659/sql-server-reporting-services-best-practices-for-performance-and-maintenance/

Similarly to https://community.powerbi.com/t5/Service/Extremely-slow-paginated-reports-due-to-high-connection-opening/m-p/1712251, I've been able to conclude that a Paginated Report connecting to a Power BI Dataset will open a new session for each dataset it needs to retrieve from the Power BI Dataset. So if you have 4 internal datasets in the Paginated Report, it will open at minimum 4 new sessions. Each session takes roughly 2 seconds to be opened.

Now, another issue we have observed is that some datasets will be retrieved from the Power BI Dataset more than once, which in turn means more new sessions being opened. We have seen datasets being retrieved even three times.

The cherry on the top is that datasets are retrieved sequentially and not concurrently from the Power BI Dataset, so all these sessions are one after another. A simple Paginated Report for us takes at 25 seconds to render, even though 3 out of 4 dataset queries finish in under 20 ms and the last query finishes in 1000 ms.

This is unacceptable... so I've raised a formal Critical ticket with Microsoft to explore why this happens and potential solutions.

For consideration:

- we use Power BI Embedded A4

- The Power BI Desktop model from which the Paginated Report reads is around 28 MB in size on disk, so technically a small dataset

- dataset queries have been tuned and tested in DAX Studio, so the performance added above is real and reproducible...

Not really a lot to go on. You could check the Issues forum here:

https://community.powerbi.com/t5/Issues/idb-p/Issues

And if it is not there, then you could post it.

If you have Pro account you could try to open a support ticket. If you have a Pro account it is free. Go to https://support.powerbi.com. Scroll down and click "CREATE SUPPORT TICKET".

I was experiencing severe performance problems until I figured out how to select the correct "level" in the Query Designer. The levels are:

Model (gold cube) >> Cubes (with the 3D arrows) > Field Name (SKIP this one) > Members or Field Name (SELECT this one).

I tried to drag and drop the first Field Name and performance was awful. I then dropped the dataset and started over using the second Field Name deeper in the node structure. Once I did this performance was awesome.

Let me know this helps.

Mike M

Avanade Power BI lead. 

Maybe your dataset is huge! Just try EnterData and add some data to explore further . Or you may use a select statement in your Dataset withr estricted data to start with. System memory isn't an issue unless a lot of data is returned in dataset.