It's important to understand the composition of frontend and backend resources in relation to Power BI workloads. For example, although a P2 capacity provides 16 total v-cores, only 8 backend cores are dedicated to processing queries, refreshing datasets, and server-side rendering of reports. Additionally, only the backend of a premium capacity node, such as the 50 GB of RAM for a P2 capacity, is exclusive to the provisioning organization. If Power BI is only being used to create reports and dashboards against DirectQuery or Live connection sources, then these backend resources are less important and the connection limit (60 per second for a P2 capacity) would be the most relevant resource to understand and monitor.
The frontend cores (8 for a P2) are shared with other organizations in a pool of servers responsible for the web service, the management of reports and dashboards, uploads/downloads, and the user experience in navigating the Power BI service generally. Organizations that utilize Power BI datasets in the default import (in-memory) mode will want to ensure sufficient RAM and backend cores are available to support both the data refresh process and the query workloads.
The following diagram illustrates the distribution of frontend and backend resources for a P2 capacity node:
As shown in this diagram, the backend of a capacity node can be thought of as a dedicated server or virtual machine with a fixed amount of CPU and RAM. It's the backend server which is responsible for the most resource-intensive or heavy lifting operations and thus should always be considered in relation to the resource needs of import mode datasets assigned to the given capacity.
In the near future, organizations will be able to fully utilize the memory included in their capacity to host even larger Power BI datasets (100 GB+), containing hundreds of millions or even billions of rows. To support these scenarios, BI teams will want to provision a capacity node with enough cores and RAM to support the data refresh operation and user queries against this dataset.
Note that this example is exclusive to import mode datasets hosted in the Power BI premium capacity (the backend server). A separate architecture and considerations for capacity nodes apply when query requests are routed to Analysis Services models via Live connection or a DirectQuery data source such as Teradata or SAP HANA. From a premium capacity perspective, in these scenarios, the BI team would need to determine via load testing and the usage metrics described in the Monitor premium capacities section of Chapter 12, Administering Power BI for an Organization, whether the query throughput limit (60 per second for P2) to these sources will be sufficient. If this throughput level is sufficient yet performance is still unacceptable, several other components of the overall solution could represent the performance bottleneck and could be evaluated separately.
These other components or factors impacting performance include the design of the data model and the efficiency or complexity of DAX measures, the design of the data source and its available resources, the design of Power BI reports (for example, quantity and type of visuals), the resources and performance of the gateway server(s) if applicable, the network connection between the Power BI service and the data source, and the level of user interactivity with reports. Techniques and practices to optimize data models and the visualization layer in Power BI are provided in the Data model optimizations and Report and visualization optimizations sections later in this chapter, respectively.