Analyze Performance

This feature is supported only in the Azure deployment version.

Data Sources: Azure Log Analytics + BI Pixie Desktop (bi-pixie.exe)

Measuring the effectiveness of your Power BI reports cannot be complete without taking into account performance data. You can extend BI Pixie capabilities beyond user engagement, adoption and satisfaction and analyze the performance of your Power BI reports by connecting BI Pixie Desktop to Azure Log Analytics. This functionality requires the Azure deployment of BI Pixie and is not supported in the Starter version.

To collect performance data in BI Pixie, your reports need to be in Power BI workspaces that are integrated with Azure Log Analytics. Microsoft describes the integration in Configure Azure Log Analytics for Power BI. Once your performance data is collected in a Log Analytics workspace, you can configure your BI Pixie function app to send queries to Log Analytics and collect the results in your BI Pixie storage account.

To start collecting performance data, you deploy BI Pixie on Azure and connect it to your Azure Log Analytics workspace, as described in this article. This is an optional feature. BI Pixie does not require you to connect to Azure Log Analytics for any other feature of BI Pixie.

With performance collection turned on in BI Pixie, you can:

• Simplify the ongoing analysis of complex performance data in Log Analytics.
• Collect the performance metrics of each visual including daily aggregates of Sum, Average, Median, 75th percentile, and 90th percentile:
  • Duration
  • Total CPU Time
  • Query Processing CPU Time
  • Vertipaq Job CPU Time
  • Execution Delay
  • Query Result Rows
• Collect these performance metrics over a long period. Log Analytics keeps data for interactive queries for up to two years, and BI Pixie keeps performance data in your storage account for longer, without a high log retention period in Log Analytics.
• Analyze any of these performance metrics in the heatmap of the Performance Heatmap tab.
• Identify slow, CPU-intense and memory-intense DAX queries over time.
• Correlate performance metrics with engagement metrics to analyze the effectiveness of your reports, pages, and visuals.
• Identify the most impacted users. BI Pixie collects viewer user names only when include_user is true in bi_pixie_config.json, and it then keeps the email address, or a masked ID when MASK_USER_NAME is true on the function app. When include_user is false, it counts viewers by a masked IP address.

Once you activate the performance collection, you can analyze the results on the Performance page of the BI Pixie Dashboard.

Performance Metrics in BI Pixie Dashboard

The Performance page in BI Pixie Dashboard includes four tabs: Performance Trends, Performance Heatmap, Performance Impact and Performance by Users. You can access them by navigating to the Performance page. With these tabs, you analyze the performance metrics of your reports and their underlying semantic models.

In the Performance Trends tab, you select one of the performance metrics (Duration, Total CPU Time, Query Processing CPU Time, and others) and one of the statistical functions (SUM, AVG, P50, P75, P90) to track the effect of your performance optimization over time. In the line charts on the right, you compare the average, median, 75th and 90th percentiles of the selected performance metric. The performance metrics reference describes each available metric.

When you point to any of the visuals in the center table, you see a tooltip with the corresponding DAX query and the measures and columns detected in it.

In the Performance Heatmap tab, you select one of the performance metrics (Duration, Total CPU Time, Query Processing CPU Time, and others) and one of the statistical functions (SUM, AVG, P50, P75, P90) to see the performance of specific report pages in the heatmap.

In the heatmap, the color of each visual represents the selected metric. When you point to a visual, you see a tooltip with the value of the selected metric, such as the 90th percentile of the visual's load duration in seconds. You can also find out which tables, columns and measures the visual uses, and how many references each one has in the visual's DAX query.

In the Performance Impact tab, you can analyze the relations between performance and engagement metrics. In the left slicer, you can select the engagement metric to analyze as the Y axis of the scatter chart. At the bottom side of the page, you can select the performance metric and the statistical function to use as the X axis of the scatter chart. The number of users is used as the size of the bubbles.

Using the scatter chart, you can find how different report pages are scattered throughout the performance and engagement dimensions. For example: you can find pages with high CPU time and low engagement. Such pages require attention as their high CPU consumption may not be justifiable.

In the Performance by Users tab, you can find the highest-CPU consuming reports and how many users are affected. You can find the top 20 impacted users and the visuals that reached the highest CPU Time.

Setting up the integration with Log Analytics

Permissions

To let BI Pixie read performance data from Log Analytics, follow these steps on the function app page in the Azure portal:

1. In the function app page, select Settings and Identity.
2. In System assigned tab, ensure the Status is On.
3. Select Azure role assignments.
4. In Azure role assignments page, select Add role assignment (Preview).
5. In Add role assignment (Preview), select Resource group in Scope.
6. Select the resource group of the Azure Log Analytics workspace in Resource group.
7. In Role, assign Log Analytics Data Reader (least privilege: query access only, scoped to the resource group of the workspace).
8. Select Save.

Schedule and other Variables

After you activate the performance collection, BI Pixie log_analytics timer function collects the performance data periodically and stores it in your storage account. By default, the timer will be triggered hourly at the first quarter of the hour and get new results since its last run. If this is the first time you run BI Pixie, it will collect the last 180 days from Log Analytics, if data is available.

To change the schedule, follow these steps on the BI Pixie function app page in the Azure portal:

1. In the function app page, select Settings.
2. Select Environment variables.
3. Edit the LOG_ANALYTICS_SCHEDULE variable.
4. Change the schedule, following the NCRONTAB expression format of Azure Functions timer triggers. The format is 6 numbers separated by a space character: {second} {minute} {hour} {day} {month} {day-of-week}. You can use wildcards (*) at the level you want to run the function. For example: “0 15 * * * *” runs the function every hour at 15 minutes and 0 seconds. “0 0 8 * * *” will run the function at 8:00am every day.
5. Select Apply. The function app will restart and the timer will activate an immediate collection of logs on start in addition to the collection of new logs following the new schedule.

To change the Log Analytics workspace ID, enter the new ID in the LOG_ANALYTICS_WORKSPACE_ID variable.

To limit the data collection to visuals that load a minimum number of rows, edit the LOG_ANALYTICS_MIN_QUERY_RESULT_ROWS variable. By default, BI Pixie collects performance data of visuals that loaded at least 10 query result rows. Query Result Rows is a Log Analytics metric that represents the number of aggregated data points in the visual. For example, a PieChart with only 2 categories has 2 rows. A scatter chart with 100 points in the visual has 100 rows.

You can limit the query results to specified workspaces by editing the PBI_WORKSPACE_IDS variable. To filter multiple workspaces, separate their IDs with commas. By default, BI Pixie collects every Power BI workspace that Log Analytics monitors. The PBI_WORKSPACE_IDS variable also filters the Power BI workspaces that BI Pixie retrieves from the tenant scan.

Using performance data as a migration baseline

If you are planning a data estate migration, such as moving semantic models to a new platform, consolidating capacities, or re-platforming reports, you can capture a performance baseline in BI Pixie before the cutover. With a baseline from before the migration, you can verify or refute a complaint that "the reports feel slower since the migration".

A practical baseline workflow:

1. Before the cutover: activate the performance collection at least a few representative weeks ahead, long enough to cover month-end or other peak windows. In the Performance Trends tab, you see the pre-migration distribution (average, median, P75, P90) per report and visual.
2. After the cutover: keep collecting on the migrated reports. Because BI Pixie retains performance history in your own storage account beyond Log Analytics' retention window, the before and after periods stay comparable side by side.
3. Root-cause regressions: compare the same visual's Duration and CPU metrics across the boundary. A slowdown isolated to specific visuals points at their DAX or the new source's query performance; a uniform shift points at capacity or gateway configuration. In the DAX query tooltips, you find the exact measures and columns involved.

You can combine the performance baseline with the data-source lineage view to scope it to the reports actually affected by the migration, and to confirm afterwards that nothing is still reading from the retired source.

What's Next

Map data sources to usage with lineage

Configure BI Pixie Desktop

Test your reports with Pixies