With the advent of ever-faster computers and the massive scale of processing available today by way of cloud computing, business users expect and demand analytical solutions that perform well. This is essential for competitive business decision-making. Business Intelligence (BI) software vendors echo this need and tend to promise quick results in their sales and marketing materials. Their expectations mean that it is uncommon to find users getting excited about how fast reports are or how fresh data is because it is something implicit to them having a positive experience.

Conversely, when users must wait a long time for a report to load, they are quite vocal and tend to escalate such issues via multiple channels. When these problems are widespread, they can damage the reputation of both software platforms and the teams involved in building and maintaining those solutions. In the worst possible case, users may refuse to adopt these solutions and management...

The next step in our performance management journey is to understand where time is spent. A Power BI solution is ultimately about exposing data to a user and can be thought of as a flow of data from source systems to data stores. Through these various components, eventually, the visual will reach a user through a browser or mobile device. A simplified view of a Power BI solution is presented in the following figure.

Figure 1.4 – Power BI solution overview

Here, we will briefly focus on the different paths of a typical solution to explain why each piece has important considerations for users and the effect poor performance can have on each process. Some of these areas will be covered in more detail in Chapter 2, Exploring Power BI Architecture and Configuration.

The following diagram highlights the areas of the solution that are affected when data sources and connectivity methods do not perform well:

Figure 1.5 – Areas affected by data source and connectivity issues

Import mode

When using Import mode datasets, developers can experience sluggish user interface responsiveness when working with Power Query or M on the desktop. In extreme cases, this can extend data transformation development from hours to days. Once the solution is deployed, problems in this area can cause refresh times to time out or fail. The Power BI service has a refresh limit of 2 hours, while Premium and Fabric capacities can extend this to 5 hours. Any refresh hitting this limit will be canceled by the system.

DirectQuery mode

DirectQuery mode leaves the data at the source and needs to fetch data and process it for measures when users interact with a report page. Issues with this part of the configuration...

As we have seen in this chapter, interacting with analytical reports is very similar to other web applications, so the user’s level of engagement and satisfaction can be measured in similar ways. Studies of use interfaces and web browsing suggest that a report that is generated in less than 5 seconds is ideal. They also suggest that reports completing in 10-second durations or higher should be considered carefully as this is the point of user frustration.

You should set performance targets and be prepared for outliers by measuring against baselines. Success may still require setting the right expectations by having different targets if you have highly complex reports.It is impotant to remember that each component of Power BI along with system resources can contribute to performance issues. Therefore, performance issues cannot be solved in isolation of just the report.

In the next chapter, we will focus on data conectivity with various storage modes of the semantic...