Kapasitetsplanlegging for paginerte rapporter

  • Artikkel

GJELDER FOR: Paginerte Power BI-rapporter Power Bi-tjeneste Power BI Desktop

Lær hvordan du planlegger Premium-kapasiteten for å få best mulig ytelse ut av de paginerte rapportene, til en minimumskostnad. Hvis du overfører til Power BI fra et annet verktøy for forretningsintelligens, kan du vurdere å lese artiklene som er oppført nedenfor, før du bestemmer deg for hvilken kapasitet du skal bruke.

Kapasitetsplanlegging

Beregning av kapasitetstypen du trenger, avhenger av flere faktorer, for eksempel antall visualobjekter i rapportene, kompleksiteten i spørringer mot rapporten og kvaliteten på datakilden eller datamodellen. Du bør også vurdere gjeldende bruk av kapasiteten i rushtiden, før du legger til paginerte rapporter i den.

Før du begynner å planlegge hvilken kapasitet du trenger, kan du se gjennom kapasitets- og SKU-tabellen for å se hvilke ressurser som tilbys av hver kapasitet.

Når du planlegger kapasiteten, bør du vurdere følgende:

  • Kompleksiteten i rapportutformingen. Nestet tablix, flere delrapporter og flere rad- og kolonnegrupper legger til kompleksiteten i utformingen, og krever kapasitetsressurser.

  • Mengden data som hentes av rapporten. Jo mer data rapporten trenger, jo flere ressurser krever den fra kapasiteten.

  • Måten rapporten henter data på. Når du bruker koblinger, drivere eller gatewayer, kan det ta lengre tid å hente data, kreve mer ressurser og dermed bli dyrere.

  • Når du eksporterer store rapporter til formater som Excel og PDF, krever det flere ressurser enn å lese hver side, bruke veksleobjekter og søke i rapportene.

Hvor mange brukere kan et SKU-håndtak?

Hvis du vil teste paginerte rapporter om ulike kapasiteter, utførte vi tre forskjellige typer arbeidsbelastninger mot forskjellige SKU-størrelser. Hver arbeidsbelastning besto av en samtidig gjengivelse av enkeltrapport, med forskjellige størrelser.

  • Liten – Dataaggregasjonstabell bygget over 100 rader fra en Azure SQL-datakilde.

  • Middels – Dataaggregasjonstabell bygget over 100 000 rader fra en Azure SQL-datakilde.

  • Stor – Dataaggregasjonstabell bygget over 250 000 rader fra en Azure SQL-datakilde.

Vår analyse for Power BI Premium viser at antall samtidige brukere til enhver tid, inkludert daglige topptider, ikke pleier å overskride fem prosent av den totale brukerbasen.

Basert på forholdet mellom fem prosent samtidighet, beskriver tabellen nedenfor det maksimale maksimale antallet brukere som en SKU kan håndtere, før den er overbelastet. Når kapasiteten er overbelastet, vil begrensning skje på kapasiteten din. Hvis du vil ha mer informasjon, kan du se Hva skjer med trafikken under overbelastning hvis jeg ikke autoskalerer?

Arbeidsbelastning F64- eller P1 SKU-er F128- eller P2 SKU-er
Liten 2500 brukere 5000 brukere
Medium 1900 brukere 3 800 brukere
Store 1300 brukere 2600 brukere

Ta hensyn til at tallene i tabellen refererer til angitte kapasiteter som ikke kjører andre operasjoner. Kapasiteten kan allerede bruke CPU-ressurser for operasjoner, for eksempel:

  • Datahenting og behandling

  • Andre arbeidsbelastnings- og bakgrunnsoperasjoner

  • Kompleks datagruppering og omforming

  • Datafiltrering

Samtidige forespørsler

Hver arbeidsbelastning på en kapasitet, inkludert arbeidsbelastningen for paginerte rapporter, har maksimalt 500 samtidige rapportgjengivelser til enhver tid. Hvis kapasiteten gjengir 100 rapporter og har 200 forespørsler om eksport av paginerte rapporter, har du 200 samtidige forespørsler om gjengivelse av rapporter igjen.

Hvis du vil unngå overbelastning, må du planlegge innlasting av samtidige forespørsler på forhånd. Hvis du overskrider grensen for samtidige forespørsler, vil du støte på feilen For mange forespørsler (429 ).

Bruke måledataappen

Ved hjelp av Microsoft Fabric Capacity Metrics-appen kan du beregne virkningen av den paginerte rapporten på kapasiteten din. Appen måler CPU-bruken over tid, slik at du kan forstå hvordan kapasiteten din fungerer.

Hvis du vil teste den paginerte rapporten, foreslår vi at du bruker en dedikert ren kapasitet. En ren kapasitet bidrar til å isolere resultater fra virkningen av andre brukere og arbeidsbelastninger.

Avhengig av det målrettede testscenarioet, for eksempel gjennomsnittlig eller maksimal bruksvalidering, velger eller oppretter du en rapportrepresentant for forventet ressursforbruk, og laster det opp til et Premium/Fabric-arbeidsområde i kapasiteten du opprettet for testen.

Kjør rapporten flere ganger, og bruk måledataappen til å få gjennomsnittlig CPU-sekunder brukt til å kjøre rapporten. Når du beregner tiden det tok å kjøre rapporten, bør du vurdere følgende:

  • Appen viser aggregerte verdier, du må kanskje dele resultatene med antall ganger du kjører rapporten.

  • Det finnes flere Power BI-elementer og -operasjoner som kan være involvert i rapportgjengivelse. Du må kanskje summere CPU-forbruket.

  • Det finnes flere Power BI-elementer og -operasjoner som kan være involvert i rapportgjengivelse, da gjengivelser kan ta lang tid. En langvarig operasjon på Timepoint-siden kan vises som en liste over operasjoner, uten at noen av varighetene er lengre enn 30 sekunder. Du må kanskje summere prosessorforbruket for gjengivelsesoperasjoner. Sortering etter starttidspunkt kan bidra til å vise hele gjengivelsesloggen.

Beregne maksimalt antall rapportgjengivelser

Bruk denne formelen til å beregne den maksimale samtidige rapporten som en kapasitet kan håndtere, før den overbelastes.

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

Beregne maksimalt antall brukere

Ved hjelp av den estimerte samtidigheten på fem prosent for korrelasjonen mellom antallet totalt antall brukere og maksimal samtidig gjengivelse, kan du få det totale antallet brukere en SKU kan håndtere.

$ \text {max SKU users} = {\text {max concurrent report renders} \over 0.05} $

Beregne kapasitetsressurser for flere rapporter

Du kan bruke en utvidet formel til å beregne kapasiteten som kreves for ulike rapportbruk.

Last opp flere paginerte rapporter med forskjellig antall daglige gjengivelser, og bruk måledataappen til å få gjennomsnittlig prosessorbehandlingstid for hver enkelt. Summen av alle rapportgjengivelsene per dag skal være lik 100 %. Når du har all informasjonen, bruker du denne formelen.

$ \text {max concurrent report renders} = {\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 processing time}}$

Eksempler

Denne delen inneholder to eksempler, ett for den vanlige beregningen og en annen for den avanserte beregningen.

Regelmessig beregning

La oss anta at du kjører en paginert rapport på en F64 - eller P1 SKU som har åtte kjerner. Den totale CPU-bruken for 10 kjøringer er 40 sekunder, så gjennomsnittlig CPU-tid per rapporter er fire sekunder.

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

Når du bruker den andre formelen, får du maksimalt 1200 brukere.

$ 1200 = {60 \over 0,05} $

For F128 - eller P2 SKU-er kan du multiplisere disse tallene med to, siden kapasiteten har dobbelt så mange CPU-kjerner.

Avansert beregning

La oss anta at du har tre paginerte rapporter med den daglige gjengivelsesprosenten oppført i tabellen nedenfor.

Report Antall gjengitte rapporter per dag Prosessorbehandlingstid (i sekunder)
A 60% 4
F 30 % 10
C 10 % 20

Formlene for en F64 eller en P1 SKU vil være:

Verdi Formel
Maksimalt antall samtidige rapportgjengivelser $ ~ 32,4 = {8 \ganger {30} \over 0,6 \ganger{4} + 0,3 \ganger{10} + 0,1 \times{20}} $
Totalt antall SKU-brukere $ ~ 650 = {32,4 \over 0,05} $

Relatert innhold