Monitoring Fabric Capacity - PowerBI Service action that blocks user action (report viewer)

[vivien57]

Hello everyone,

The context is as follows: some users sometimes complain that the first access to the dashboard is slow.

So the first thing we did was to look at Fabric capacity utilisation. It's healthy and our F64 meets our needs.

However, as I looked at more and more precise timeframes (every time a user reported a slow connection), I noticed the following:

The user toto clicked to open the Power BI report at around 3:33, but his request was put on hold (on the screen the user sees that the process is loading).

In fact, it is a process run by the "Power BI Service" that is executed initially (red line), and which lasts 72 seconds... Once this process has finished (which has blocked the user's request until now), the report opens on the user's screen (yellow line) instantly (0 seconds).

I also asked another user shortly after 3:37 (blue line) to open the same report and it instantiated (the Power BI Service process didn't restart), so he took advantage of the previous user's wait.

My question is, do you know what this process is that blocks the first user's request ? Because in the end the report is very fast, but the user has a bad experience because a longer process is triggered with his request.

For information, the dataset had been refreshed in the morning at around 10am, so it wasn't being refreshed at the time of the users actions.

Thank in advance for your return,

have a nice day,

Vivien

[v-huijiey-msft]

Hi @vivien57 ,

When a user accesses a report for the first time, the Power BI service may need to perform several initial tasks, such as loading the report's metadata, establishing connections, and preparing the data model. This can cause delays.

I noticed that the access time is 3:33 PM, when there may be many users accessing content in the power bi service at the same time, at this point the initial request for users to access this dataset may be delayed due to too many sessions.

I have the following suggestions:

Ensure that reports are optimized for performance. For example, reducing the number of visual objects, using appropriate data models, and reducing the complexity of calculations.

More information on how to optimize can be found in the link below:

Optimization guide for Power BI - Power BI | Microsoft Learn

Optimize a model for performance in Power BI - Training | Microsoft Learn

Consider accessing reports during off-peak hours, this should help.

If you have any other questions please feel free to contact me.

Best Regards,
Yang
Community Support Team

If there is any post helps, then please consider Accept it as the solution  to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let us know. Thanks a lot!

[vivien57]

Hello @v-huijiey-msft 

Thank you for your feedback.

What do you mean by first time? Because the report has been available for a long time, the refresh was done in the morning and users have also accessed it before.

What's more, there are no competing access issues, because we're on Fabric F64 capacity and we've never achieved Throtting that triggers Interactive Delay.

Finally, I don't think it's a report performance problem, because otherwise most of the user reports on this report would be affected. This is not the case, because the report is very fast (when the process mentioned is not triggered).

However, here we're in a case where PowerBI itself triggers a process, so I think it would be relevant to know what causes this process to be triggered, when it's triggered, and so on.

Do you have this information?

Thank you in advance for your return,

Have a nice day,

Vivien