Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Compete to become Power BI Data Viz World Champion! First round ends August 18th. Get started.

0

Inconsistent load and render times for embedded report

Good morning,

we have an embedded report running inside an Angular 8 application that is viewed by users spread across different locations (namely UK, India, Brazil, and Spain), and we have noticed the report is taking an unpredictable amount of time to load and render for each of those user's sessions, seemingly without any one cause that could be identified. These load and render times vary each from a minimum of about 3 seconds to sometimes 30, or even up to nearly 45 seconds. The table below shows the average, longest, and shortest load times for seven of those users, in milliseconds:

AverageLoadTime.png

 

This next table shows the average, longest, and shortest render times for those same users, in milliseconds:

AverageRenderTime.png

 

As you can see, for one of our users in Spain, the time it took the report to render ranged from 5.5s to a whopping 44s. Another user in the same country (represented in the seventh row of both tables) had a much more consistent range of 2.9s to 3.2s. These tests have been conducted with different browsers and OS's. This table shows each of those entries, ordered by user/region and duration of the load phase. This other table  shows, likewise, the duration of each render time.

 

It's important to notice that, during some attempts to view the report, it got stuck at either the load phase or the render phase, to the point where users were forced to refresh the page and our application was therefore unable to register the time it had taken thus far. We can know for sure that, albeit at those exceptional occurrences, the total time it took for the report never to appear exceeded the two-minute mark.

 

To obtain those numbers, we have subscribed to events fired by the Power BI embed script, namely "loaded" and "rendered". On the other hand, the initial request that returns the embedToken, prior to these two phases, has had consistent, very good performance, so much so we have not felt it necessary to include their duration in those tables.

 

We can gladly collect and share more data if it assists you in the analysis of this issue, and if there is anything we can do at the moment to improve this scenario, we will appreciate it very much if you can show us.

 

Thank you,

 

-- Daniel.

Status: Delivered

Hi @marcelobelchior ,

 

It’s hard to make the load and render time consistent. According to the design of Power BI, to display the report for the users, Power BI needs to load the report dataset to memory firstly. But normally, the memory resources are shared with others. If the report is in Shared capacity, then resources are shared with users supported by the Power BI data center. If the report is in a PPU capacity or Premium capacity, then resources are shared with all PPU license users or organizational users. If the resources are not enough, the dataset must wait for the resources. After loading the dataset into memory, Power BI needs to expand the dataset, read the report metadata and query for visual data etc. to render the report. This is why it’s hard to consist the load/render time for every users.

 

But you don’t need to worry about it. Normally, Power BI will try the best to render the report for users in short time. If you see it gets suck in loading/rendering, you could refresh your browser to re-render of it.

 

Best Regards,

Community Support Team _ Caiyun

Comments
v-cazheng-msft
Community Support
Status changed to: Delivered

Hi @marcelobelchior ,

 

It’s hard to make the load and render time consistent. According to the design of Power BI, to display the report for the users, Power BI needs to load the report dataset to memory firstly. But normally, the memory resources are shared with others. If the report is in Shared capacity, then resources are shared with users supported by the Power BI data center. If the report is in a PPU capacity or Premium capacity, then resources are shared with all PPU license users or organizational users. If the resources are not enough, the dataset must wait for the resources. After loading the dataset into memory, Power BI needs to expand the dataset, read the report metadata and query for visual data etc. to render the report. This is why it’s hard to consist the load/render time for every users.

 

But you don’t need to worry about it. Normally, Power BI will try the best to render the report for users in short time. If you see it gets suck in loading/rendering, you could refresh your browser to re-render of it.

 

Best Regards,

Community Support Team _ Caiyun

marcelobelchior
Regular Visitor

Thank you for your reply, but we still have some inquiries, if you'd be so kind to respond.

 

To begin with, it's important to note that our resources are indeed at Premium capacity already. As we see it, it's rather urgent that Microsoft escalate the resources available to such top-tier users, so that they and their consumers may get more consistent load and render times. As for the unfortunate scenario where the report gets stuck while loading, it can surely be coded around with some creativity, but we do make a point of emphasizing this problem could be a potential source of embarrassment for organizations.

Now, if there are other alternatives that might help us achieve the goal of providing at least more consistent load and render times for our users, we would like to know what they are so that an appropriate strategy may be designed accordingly.

AlexNTH
Regular Visitor

Hey, my team is currently dealing with inconsistent load times as well. On average our load time is between 8-15 seconds, but there are at least 2 - 3 users each day (we average less than 100 users a day) which will experience a load time over 30 seconds, the longest being ~70seconds.

The report works great after being loaded, which is great. But the product owner on our team voices concerns of these long initial load times that  could be quite embarrassing for our company, and I can agree with this sentiment.

I wanted to check if any solution was found for compensating these inconsistencies