Forstå kjørefaser, dataoppkallsflyter og ytelsesovervåkning for lerretsapper

Når en bruker åpner en lerretsapp, går den gjennom flere kjørefaser før du ser et brukergrensesnitt. Mens appen lastes inn, kobler den til ulike datakilder—for eksempel SharePoint, Microsoft Dataverse, SQL Server (lokalt), Azure SQL Database (online), Excel og Oracle.

I denne artikkelen får du informasjon om disse ulike kjørefasene, hvordan en app kobles til datakildene, og om verktøyene du kan bruke til å overvåke ytelsen.

Kjørefaser i lerretsapper

En lerretsapp går gjennom følgende kjørefaser før grensesnittet vises for en bruker:

1. Godkjenne brukeren: Ber den første brukeren om å logge på med legitimasjon for de tilkoblingene appen trenger. Hvis den samme brukeren åpner appen på nytt, kan det hende vedkommende blir spurt på nytt, men det er avhengig av organisasjonens sikkerhetspolicyer.

2. Hent metadata: Henter metadata som for eksempel versjonen av Power Apps-plattformen der appen kjører, og kildene til datahentingen.

3. Initialiserer appen: Utfører de oppgavene som er angitt i OnStart-egenskapen.

4. Gjengi skjermene: Gjengir den første skjermen med kontroller som appen fyller med data. Hvis brukeren åpner de andre skjermbildene, gjengir appen dem ved å bruke den samme prosessen.

Datakallflyt i lerretsapper

Dataoppkall fra lerretsapper sender data til tabulære datakilder ved å bruke koblinger over OData-protokollen. OData-forespørsler flyter til serverdellagene for å nå måldatakilden og hente data for klienten, eller lagre data i datakilden. Handlingsbaserte koblinger som aktiverer API-er, fungerer på samme måte.

Forståelse av hvordan OData- og API-forespørsler overføres i lerretsapper, kan hjelpe deg å optimalisere ytelsen til lerretsappen og serverdeldatakildene.

I denne delen lærer du om hvordan datakallet flyter i lerretsapper med forskjellige datakildetyper.

Datakallflyt med online datakilder

Følgende diagram viser hvordan en typisk dataforespørsel i en lerretsapp (venstre side) reiser gjennom lagene på serversiden og når ut til måldatakilden (høyre side), og returnerer deretter dataene til klienten.

Hvert lag i det foregående diagrammet kan yte raskt eller ha noen ekstra kostnader under behandling av forespørselen. I mange apper kan det hende at to bestemte punkter vanligvis viser merkbare indirekte kostnader:

• Serverdeldatakilde under behandling av forespørselen.

• Klient under sending av forespørselen eller under manipulering av de mottatte dataene i heap-minnet og kjøring av de tilknyttede JavaScript-funksjonene for å behandle data som skal vises inne på skjermene.

Datakallflyt med lokal datagateway

Hvis en lerretsapp kobler til en lokal datakilde for eksempel SQL Server, må du ha et annet lag, kalt for lokal datagateway. Denne gatewayen er obligatorisk for tilgang til lokal datakilder. Den tar ansvaret for å konvertere OData-protokollforespørsler til SQL DML-setninger (datamanipulasjonsspråk).

Følgende diagram viser hvor og hvordan den lokale datagatewayen er plassert for å behandle dataforespørsler.

Hvis appen bruker en datakilde lokalt, vil plasseringen og spesifikasjonen for datagatewayen også påvirke ytelsen til datakall.

Dataoppkallsflyt med Microsoft Dataverse

Når du bruker Microsoft Dataverse som datakilden, går dataforespørsler direkte til miljøforekomsten uten å gå gjennom Azure API Management. Ytelsen til dataoppkall er derfor raskere sammenlignet med resten av datakildene. Appen kobles som standard til Microsoft Dataverse når du oppretter en ny lerretsapp.

Med forståelsen av dette konseptet på høyt nivå om hvordan datakall reiser, kan du sette deg inn i detaljene i ytelsesgjennomgangen av appen. Oppsummert kan ytelseskostnader skje på et hvilket som helst lag – fra klient, APIM (API Management), kobling, lokal datagateway og serverdeldatakilder.

Måle ytelse

Overvåkingsverktøy i Power Apps

Selv om du kan bruke nettleserens utviklerverktøy til å vise ytelse, setter Power Apps settet med oppkall i overvåkingsverktøyet til bare de som er Power Apps.

Overvåkningsverktøyet i Power Apps kan hjelpe deg å spore hva som faktisk sendes til datakilden og setter tidsstempler for når forespørsler sendes og svar kommer fra serveren.

Du kan finne ut mer om overvåkningsverktøyet i denne artikkelen: Feilsøking av lerretsapper med Overvåk.

Måling av minnetrykk på klienten

Hvis du vil vise minneforbruk grafisk, kan du bruke utviklerverktøyene for nettleseren til å profilere minne. Det hjelper deg med å visualisere heap-størrelse, dokumenter, noder og lyttere. Profiler appens ytelse ved hjelp av en nettleser, som beskrevet i Oversikt over utviklerverktøy for Microsoft Edge (Chromium). Kontroller scenariene som overskrider minneterskelen for JS-heapen. Mer informasjon: Løse minneproblemer

Neste trinn

Små datanyttelaster

Se også

Feilsøking av problemer for Power Apps

Obs!

Kan du fortelle oss om språkinnstillingene for dokumentasjonen? Ta en kort undersøkelse. (vær oppmerksom på at denne undersøkelsen er på engelsk)

Undersøkelsen tar rundt sju minutter. Det blir ikke samlet inn noen personopplysninger (personvernerklæring).