Forum Discussion

mmouton's avatar
mmouton
Frequent Visitor
10 months ago

Poor performance with Power BI API for paginated reports compared to SSRS

Hello,

We are moving a series of paginated reports from SSRS (on-premise) to Power BI. The .rdl files are hosted on a workspace licensed by a Fabric capacity F4.

I have migrated the reports to Power BI and configured an on-premise gateway to query an on-premise SQL Server. The reports are built using DirectQuery. I have built a small C# app which uses the Power BI API to generate reports. Everything is working well except for the performance.

Here are some timings using the same report, same parameters, and same database:

  • T1 - Time to generate a report from legacy SSRS server: 22s
  • T2 - Time to render report from app.powerbi.com using web interface: 33s
  • T3 - Time to export report as PDF from app.powerbi.com using web interface: 20s
  • T4 (= T2+T3) - Time to render and export report as PDF from app.powerbi.com using web interface: 55s
  • T5 - Time to generate report using Power BI API: 83s

Notes:

  • The waiting time between polling is set to 1s, which leads to a small delay, but it is not the origin of my problem.
  • I changed my capacity from F2 to F4 with no effect.
  • RAM and CPU on the on-premise Power BI gateway are not overloaded.

I can understand that timings are not the same when moving from on-premise to cloud features, but I expected that T4 should be close to T5. Right now, generating a report is 4 times slower after migration, and this is not acceptable for users.

 

Can it be a bug on the powerbi api ? 

What can I do to improve performances ? 

Need Help

4 Replies

  • rohit1991's avatar
    rohit1991
    Super User
    10 months ago

    Hi mmouton 

    Performance is slower with Power BI Paginated Report API than SSRS because rendering in Power BI runs through additional cloud service layers, capacity limits, and gateway latency, unlike SSRS which runs fully on-prem. This is expected behavior, not a bug.

    To improve performance:

    1. Optimize report queries and reduce data volume.

    2. Simplify report layout (fewer visuals, subreports, expressions).

    3. Use the Paginated Report Diagnostics tool to find bottlenecks.

    4. Ensure your Fabric capacity isn’t throttled.

    5. Minimize gateway latency or move data closer to Power BI (e.g., Azure SQL).

    https://darren.gosbell.com/2023/10/diagnosing-performance-of-paginated-reports-in-power-bi/?utm 

    https://learn.microsoft.com/en-in/power-bi/guidance/report-paginated-performance-scalability-considerations 

    If the above steps don’t improve performance, here’s the next level of action:

    1. Switch from DirectQuery to Import mode (if possible).

      • DirectQuery causes repeated round-trips through the gateway for every query.

      • Import mode caches data in Fabric, giving up to 5–10× faster rendering.

    2. Run reports in Power BI Report Builder (desktop) for critical use cases faster than cloud rendering because it skips Fabric service overhead.

    3. Scale up capacity to F8 or highe - paginated reports benefit from more RAM and rendering threads.

    4. Move your SQL source to Azure (PaaS) - reduces gateway latency drastically compared to on-prem SQL.

    5. Raise a Microsoft support ticket - if diagnostics show normal query time but high “rendering” time, it may be a Fabric backend issue.
      https://support.fabric.microsoft.com/ 

  • v-aatheeque's avatar
    v-aatheeque
    Community Support
    10 months ago

    Hi mmouton 

    Just checking in to see if the previous response helped resolve your issue which was shared by rohit1991 . If not, feel free to share your questions and we’ll be glad to assist.

  • mmouton's avatar
    mmouton
    Frequent Visitor
    10 months ago

    Hi,

    The previous response is very comprehensive. I'm comparing performance for one report, but I'm moving around 80 reports from SSRS to Power BI.

    I don't see how optimizing queries or reducing data volume can have a significant impact because the reports are working, the database can easily handle requests and loadings.

    We've already worked on report optimization and it seems very painful to re-iterate through all reports...

    Fabric capacity isn't throttled.

    Again, thank you for taking the time to answer my question, but I'm disappointed that the options seem very heavy (moving data to Azure SQL, redesigning reports) in regard to the problem (moving from on-premise to Power BI).

    • v-aatheeque's avatar
      v-aatheeque
      Community Support
      10 months ago

      Hi mmouton 

      Thanks for getting back and sharing those details. It looks like you’ve already gone through the suggestions shared by rohit1991 around gateway setup, capacity checks, and report performance tweaks.

      Since the issue is still happening even after those steps, have you had a chance to raise a support ticket with Microsoft yet? That would let the backend team review your Fabric capacity logs in detail and see if there’s any service-related latency or delay causing this.
      Microsoft Fabric Support and Status | Microsoft Fabric