Optimaliseringsveiledning for Power BI

Denne artikkelen inneholder veiledning som gir utviklere og administratorer muligheten til å produsere og opprettholde optimaliserte Power BI-løsninger. Du kan optimalisere løsningen på forskjellige arkitektoniske lag. Lag inkluderer:

  • Datakildene
  • Datamodellen
  • Visualiseringer, inkludert instrumentbord, Power BI-rapporter og Power BI-sideformaterte rapporter
  • Miljøet, inkludert kapasiteter, datagatewayer og nettverket

Optimalisering av datamodellen

Datamodellen støtter hele visualiseringsfunksjonen. Datamodeller er enten ekstern- eller intern-vertsbaserte, og i Power BI refereres de til som datasett. Det er viktig at du forstår alternativene og velger riktig datasetttype for løsningen. De tre datasettmodusene er: Import, DirectQuery og kompositt. Hvis du vil ha mer informasjon, kan du se Datasett i Power BI-tjenesten og Datasettmoduser i Power Bi-tjenesten.

Her finner du spesifikk veiledning for datasettmodus:

Optimalisering av visualiseringer

Power BI-visualiseringer kan være instrumentbord, Power BI-rapporter eller Power BI-sideformatere rapporter. De har ulike arkitekturer, og hver av dem har sin egen veiledning.

Instrumentbord

Det er viktig å forstå at Power BI har en hurtigbuffer for instrumentbordflisene dine – bortsett fra aktive rapportfliser og strømmefliser. Hvis du vil ha mer informasjon, kan du se Dataoppdatering i Power BI (flisoppdatering). Hvis datasettet håndhever dynamisk sikkerhet på radnivå (RLS), er det viktig at du forstår ytelsesimplikasjonene, siden fliser blir bufret på en per bruker-basis.

Når du fester aktive rapportfliser til et instrumentbord, blir de ikke sendt fra spørringsbufferen. De fungerer i stedet som rapporter, og sender spørringer til serverdelkjerner mens de er i gang.

Hvis du vil hente data fra hurtigbufferen, kan du ikke bare stole på datakilden. Da trenger du en bedre og mer konsekvent ytelse, slik navnet antyder. En måte du kan dra nytte av denne funksjonaliteten på, er å gjøre instrumentbordet til den første siden brukerne kommer til. Fest ofte brukte og forespurte visualobjekter til instrumentbordene. Slik blir instrumentbord en verdifull forsvarslinje som gir konsekvent ytelse med mindre belastning på kapasiteten. Brukere kan fortsatt klikke seg frem til en rapport for å analysere detaljer.

Når det gjelder DirectQuery og live-tilkoblinger, oppdateres hurtigbufferen med jevne mellomrom ved å spørre datakilden. Som standard skjer det hver time, men du kan konfigurere en annen frekvens i datasettinnstillingene. Hver oppdatering av hurtigbufferen sender spørringene til den underliggende datakilden, slik at hurtigbufferen kan oppdateres. Antall spørringer som genereres, avhenger av hvor mange visualobjekter som er festet på instrumentbord som er avhengig av denne datakilden. Obs! Hvis sikkerhet på radnivå er aktivert, genereres spørringer etter hver enkelt sikkerhetskontekst. Tenk deg at det finnes to forskjellige roller som kategoriserer brukerne, og de har to forskjellige visninger av dataene. Under oppdatering av spørringsbufferen oppretter Power BI to sett med spørringer.

Power BI-rapporter

Det finnes flere anbefalinger for optimalisering av rapportutforminger i Power BI.

Obs!

Når rapporter er basert på et DirectQuery-datasett, kan du se Veiledning for DirectQuery-modeller i Power BI Desktop (Optimaliser rapportutforminger) for flere optimaliseringer for rapportutforming.

Bruk de mest restriktive filtrene

Jo mer data et visualobjekt skal vise, desto saktere blir visualobjektet lastet inn. Selv om dette prinsippet virker åpenbart, er det lett å glemme. Se for eksempel for deg at du har et stort datasett. Over det datasettet oppretter du en rapport med en tabell. Sluttbrukere bruker slicere på siden for å vise radene de ønsker. Vanligvis er de bare interesserte i et titalls rader.

En vanlig feil er å ikke filtrere standardvisningen i tabellen, det vil si alle de 100 000 radene. Dataene til disse radene lastes inn i minnet og dekomprimeres ved hver oppdatering. Denne behandlingen setter store krav til minne. Løsning: Bruk «Top N»-filteret til å redusere det maksimale elementantallet som vises i tabellen. Du kan angi det maksimale elementantallet til mer enn det brukerne trenger, for eksempel 10 000. Resultatet er at sluttbrukeropplevelsen ikke endres, men minnebruken reduseres mye. Og det viktigste er at ytelsen blir forbedret også.

En lignende utformingsmetode som ovenfor foreslås for alle visualobjekter i rapporten. Still deg selv spørsmålet, trenger jeg alle disse dataene i visualobjektet? Er det andre måter jeg kan filtrere dataene som vises i visualobjektet på, slik at de reduseres i antall, og uten at det gjør noe med brukeropplevelsen? Husk at tabeller kan være veldig dyre.

Begrens visualobjekter på rapportsidene

Prinsippet ovenfor gjelder også for antall visualobjekter lagt til på en rapportside. Vi anbefaler at du begrenser antallet visualobjekter på en rapportside til det høyst nødvendige. Ekstrahering av sider og verktøytips for rapportsider er gode måter å gi flere detaljer på, uten å presse inn flere visualobjekter på siden.

Vurder tilpasset ytelse for visualobjekter

Sørg for å teste ut hvert tilpasset visualobjekt, for å sikre høy ytelse. Power BI-visualobjekter som ikke er optimalisert godt nok, kan ha en negativ innvirkning på hele rapportytelsen.

Sideformaterte rapporter for Power BI

Utforming av Power BI-sideformaterte rapporter kan optimaliseres ved å bruke anbefalt fremgangsmåte i rapportens datahenting. Hvis du vil ha mer informasjon, kan du se Veiledning for datahenting for paginerte rapporter.

Forsikre deg om at kapasiteten har tilstrekkelig minne tilordnet arbeidsmengden for sideformaterte rapporter.

Optimalisering av miljøet

Du kan optimalisere Power BI-miljøet ved å konfigurere kapasitetsinnstillinger, skalere datagatewayer og redusere nettverksventetid.

Kapasitetsinnstillinger

Når du bruker kapasiteter – tilgjengelige med Power BI Premium (P-ASK-er), Premum per bruker (PPU)-lisenser, eller Power BI Embedded (A-A-A-er, A4-A6)-, kan du administrere kapasitetsinnstillinger. Du finner mer informasjon i Behandling av Premium-kapasiteter. For veiledning om hvordan du optimaliserer kapasiteten, kan du se Optimalisering av Premium-kapasiteter.

Gateway-skalering

En gateway er nødvendig når Power BI trenger tilgang til data som ikke er tilgjengelig direkte over Internett. Du kan installere den lokale datagatewayen på en lokal server eller en virtuell maskin som er vert for infrastruktur som tjeneste (IaaS).

For å forstå arbeidsbelastninger og størrelsesanbefalinger for gatewayer kan du se Lokal datagateway-skalering.

Nettverksventetid

Nettverksventetid kan påvirke rapportytelsen ved å øke tiden det tar å sende forespørslene til Power BI-tjenesten, og tiden det tar å levere svarene. Tenanter i Power BI tilordnes en bestemt region.

Tips!

Hvis du vil finne ut hvor Power BI-tenanten er plassert, kan du se Hvor er Power BI-tenanten min plassert?

Når brukere fra en leier åpner Power BI-tjenesten, distribueres alltid forespørslene til dette området. Når forespørslene mottas av Power BI-tjenesten, kan tjenesten sende flere forespørsler, for eksempel til den underliggende datakilden eller datagatewayen, som også er underlagt nettverksventetid.

Verktøy som Azure Speed Test kan gi deg et inntrykk av nettverksventetiden mellom klienten og Azure-regionen. Hvis du vil minimere påvirkningen av nettverksventetid, bør du holde datakilder, gatewayer og Power BI-klyngene så nære som mulig. Forhåpentligvis er de plassert i samme område. Hvis nettverksventetid er et problem, kan du prøve å finne gatewayer og datakilder som er nærmere Power BI-klyngen, ved å legge dem i skybaserte virtuelle maskiner.

Overvåker ytelse

Du kan overvåke ytelse for å identifisere flaskehalser. Trege spørringer, eller visualobjekter i rapporter, bør være et fokuspunkt for videre optimalisering. Overvåking kan utføres i løpet av utforming i Power BI Desktop eller på produksjonsarbeidsbelastninger i Power BI Premium-kapasiteter. Hvis du vil ha mer informasjon, kan du se Overvåke rapportytelse i Power BI.

Neste trinn

Du finner mer informasjon om denne artikkelen i følgende ressurser: