Share via

Capaciteitsplanning voor gepagineerde rapporten

  • Artikel

VAN TOEPASSING OP: Gepagineerde Power BI-rapporten Power BI-service Power BI Desktop

Meer informatie over het plannen van uw Premium-capaciteit om de beste prestaties uit uw gepagineerde rapporten te halen, tegen minimale kosten. Als u migreert naar Power BI vanuit een ander hulpprogramma voor bedrijfsinformatie, kunt u overwegen de onderstaande artikelen te lezen voordat u bepaalt welke capaciteit u wilt gebruiken.

Capaciteitsplanning

Het berekenen van het type capaciteit dat u nodig hebt, is afhankelijk van verschillende factoren, zoals het aantal visuals in uw rapporten, de complexiteit van query's voor het rapport en de kwaliteit van uw gegevensbron of gegevensmodel. U moet ook rekening houden met het huidige gebruik van uw capaciteit tijdens piektijden voordat u gepagineerde rapporten eraan toevoegt.

Voordat u begint met het plannen van de capaciteit die u nodig hebt, bekijkt u de tabel Capaciteiten en SKU's om te zien welke resources door elke capaciteit worden aangeboden.

Houd rekening met het volgende wanneer u uw capaciteit plant:

  • De complexiteit van het rapportontwerp. Geneste tablix, meerdere subrapporten en meerdere rij- en kolomgroepen voegen de complexiteit van het ontwerp toe en vereisen capaciteitsbronnen.

  • De hoeveelheid gegevens die door het rapport wordt opgehaald. Hoe meer gegevens het rapport nodig heeft, hoe meer resources het nodig heeft vanuit uw capaciteit.

  • De manier waarop uw rapport gegevens ophaalt. Wanneer u connectors, stuurprogramma's of gateways gebruikt, kan het ophalen van gegevens langer duren, meer resources vereisen en daardoor duurder worden.

  • Wanneer u grote rapporten exporteert naar indelingen zoals Excel en PDF, hebt u meer resources nodig dan elke pagina te lezen, wisselknoppen te gebruiken en in de rapporten te zoeken.

Hoeveel gebruikers kunnen een SKU verwerken?

Om gepagineerde rapporten over verschillende capaciteiten te testen, hebben we drie verschillende typen workloads uitgevoerd op basis van verschillende SKU-grootten. Elke workload bestond uit een gelijktijdig rendering van één rapport, met verschillende grootten.

  • Klein : gegevensaggregatietabel die is opgebouwd uit meer dan 100 rijen uit een Azure SQL-gegevensbron.

  • Gemiddeld : gegevensaggregatietabel die meer dan 100.000 rijen uit een Azure SQL-gegevensbron heeft gebouwd.

  • Grote tabel voor gegevensaggregatie die meer dan 250.000 rijen uit een Azure SQL-gegevensbron heeft gebouwd.

Uit onze analyse voor Power BI Premium blijkt dat het aantal gelijktijdige gebruikers op elk gewenst moment, inclusief dagelijkse piektijden, niet meer dan vijf procent van het totale gebruikersbestand overschrijdt.

Op basis van de verhouding van vijf procent gelijktijdigheid beschrijft de volgende tabel het geschatte maximum aantal gebruikers dat een SKU kan verwerken voordat deze overbelast is. Wanneer uw capaciteit overbelast is, treedt er beperking op uw capaciteit op. Zie Wat gebeurt er met verkeer tijdens overbelasting als ik niet automatisch schaalaanpassing?

Workload F64- of P1-SKU's F128- of P2-SKU's
Small 2500 gebruikers 5000 gebruikers
Gemiddeld 1900 gebruikers 3.800 gebruikers
Large 1300 gebruikers 2.600 gebruikers

Houd er rekening mee dat de getallen in de tabel verwijzen naar aangewezen capaciteiten die geen andere bewerkingen uitvoeren. Uw capaciteit kan al CPU-resources gebruiken voor bewerkingen zoals:

  • Gegevens ophalen en verwerken

  • Andere workload- en achtergrondbewerkingen

  • Complexe gegevensgroepering en -hervorming

  • Gegevens filteren

Gelijktijdige aanvragen

Elke workload op een capaciteit, inclusief de workload gepagineerde rapporten, heeft op elk gewenst moment maximaal 500 gelijktijdige rapportweergaven. Als uw capaciteit 100 rapporten weergeeft en 200 aanvragen heeft voor het exporteren van gepagineerde rapporten, hebt u nog 200 gelijktijdige rapportweergaveaanvragen.

Om congestie te voorkomen, plant u de belasting van uw gelijktijdige aanvragen vooraf. Als u de limiet voor gelijktijdige aanvragen overschrijdt, krijgt u de fout Te veel aanvragen (429).

De app voor metrische gegevens gebruiken

Met behulp van de microsoft Fabric Capacity Metrics-app kunt u een schatting maken van de impact van uw gepagineerde rapport op uw capaciteit. De app meet uw CPU-gebruik in de loop van de tijd, zodat u begrijpt hoe uw capaciteit presteert.

Als u uw gepagineerde rapport wilt testen, raden we u aan een toegewezen schone capaciteit te gebruiken. Een schone capaciteit helpt resultaten te isoleren van de impact van andere gebruikers en workloads.

Afhankelijk van het doeltestscenario, bijvoorbeeld gemiddelde of maximale gebruiksvalidatie, selecteert of maakt u een rapportvertegenwoordiger van het verwachte resourceverbruik en uploadt u het naar een Premium/Fabric-werkruimte in de capaciteit die u voor de test hebt gemaakt.

Voer het rapport meerdere keren uit en gebruik de app met metrische gegevens om de gemiddelde CPU-seconden op te halen die zijn besteed aan het uitvoeren van uw rapport. Houd rekening met het volgende bij het berekenen van de tijd die nodig was om uw rapport uit te voeren:

  • In de app worden geaggregeerde waarden weergegeven. Mogelijk moet u de resultaten delen door het aantal keren dat u het rapport uitvoert.

  • Er zijn meerdere Power BI-items en -bewerkingen die mogelijk betrokken zijn bij het weergeven van rapporten. Mogelijk moet u het CPU-verbruik optellen.

  • Er zijn meerdere Power BI-items en -bewerkingen die mogelijk betrokken zijn bij het weergeven van rapporten, omdat het weergeven van rapporten lang kan duren. Een langlopende bewerking op de pagina Timepoint kan worden weergegeven als een lijst met bewerkingen, met geen van de duurs langer dan 30 seconden. Mogelijk moet u het CPU-verbruik van renderbewerkingen optellen. Door te sorteren op de begintijd kunt u de volledige geschiedenis van de weergave weergeven.

Het maximum aantal rapportweergaven berekenen

Gebruik deze formule om het maximum aantal gelijktijdige rapporten te berekenen dat een capaciteit kan verwerken voordat deze overbelast raakt.

$ \text {max concurrent report renders} = {\text {number of capacity SKU cores} \times {30} \over \text {the report's CPU processing time (in seconds)}} $

Het maximum aantal gebruikers berekenen

Met behulp van de geschatte vijf procent gelijktijdigheid voor de correlatie tussen het aantal totale gebruikers en de maximale gelijktijdige renders, kunt u het aantal totale gebruikers krijgen dat een SKU kan verwerken.

$ \text {max SKU users} = {\text {max gelijktijdige rapport renders} \meer dan 0,05} $

Capaciteitsbronnen voor meerdere rapporten berekenen

U kunt een uitgebreide formule gebruiken om de capaciteit te schatten die nodig is voor verschillende rapportgebruiken.

Upload verschillende gepagineerde rapporten met een verschillend aantal dagelijkse renders en gebruik de app met metrische gegevens om de gemiddelde CPU-verwerkingstijd voor elk rapport op te halen. De som van alle rapporten die per dag worden weergegeven, moet gelijk zijn aan 100%. Wanneer u alle informatie hebt, gebruikt u deze formule.

$ \text {max gelijktijdige rapportweergaven} = {\text {number of capacity SKU cores} \times {30} \over {\text {A renders} \times \text {A processing time}} + \text {B renders} \times \text {B processing time} + \text {...} + \text{N renders} \times \text{N verwerkingstijd}}$

Voorbeelden

Deze sectie bevat twee voorbeelden, een voor de reguliere berekening en een andere voor de geavanceerde berekening.

Reguliere berekening

Stel dat u een gepagineerd rapport uitvoert op een F64 - of P1-SKU met acht kernen. Het totale CPU-gebruik voor 10 uitvoeringen is 40 seconden, dus de gemiddelde CPU-tijd per rapport is vier seconden.

$ 60 = {8 \times {30} \over 4} $

Wanneer u de tweede formule gebruikt, krijgt u maximaal 1200 gebruikers.

$ 1.200 = {60 \meer dan 0,05} $

Voor F128 - of P2-SKU's kunt u deze getallen met twee vermenigvuldigen, omdat de capaciteit tweemaal het aantal CPU-kernen heeft.

Geavanceerde berekening

Stel dat u drie gepagineerde rapporten hebt met het dagelijkse renderingpercentage dat in de onderstaande tabel wordt vermeld.

Rapport Aantal weergegeven rapporten per dag CPU-verwerkingstijd (in seconden)
A 60% 4
B 30% 10
E 10% 20

De formules voor een F64- of P1-SKU zijn:

Weergegeven als Formule
Maximaal aantal gelijktijdige rapportweergaven $ ~32,4 = {8 \times {30} \over 0,6 \times{4} + 0,3 \times{10} + 0,1 \times{20}} $
Totaal aantal SKU-gebruikers $ ~650 = {32,4 \meer dan 0,05} $

Gerelateerde inhoud