Om udførelsesfaser for lærredsapps, dataopkaldsflow og overvågning af ydeevne

Når en bruger åbner en lærredapp, gennemgår appen flere kørselsfaser, inden der vises en brugergrænseflade. Mens appen indlæses, oprettes der forbindelse til forskellige datakilder—f.eks. SharePoint, Microsoft Dataverse SQL Server (i det lokale miljø), Azure SQL Database (online), Excel og Oracle.

I denne artikel får du mere at vide om de forskellige kørselsfaser, og hvordan appen opretter forbindelse til datakilder og om de værktøjer, du kan bruge til overvågning ydeevne.

Kørselsfaser i lærredapps

En lærredsapp gennemgår følgende kørselsfaser, inden grænsefladen vises for en bruger:

1. Godkend brugeren: Beder første gang brugeren om at logge på med legitimationsoplysningerne for de forbindelser, appen skal bruge. Hvis den samme bruger åbner appen igen, kan den pågældende blive bedt om det igen, afhængigt af organisationens sikkerhedspolitikker.

2. Hent metadata: Henter metadata, f.eks. versionen af den Power Apps-platform, appen kører på, og de datakilder, den skal hente data fra.

3. Initialiser appen: Udfører de opgaver, der er angivet i egenskaben OnStart.

4. Gengiv skærmbilleder: Gengiver det første skærmbillede med de kontrolelementer, appen har udfyldt med data. Hvis brugeren åbner andre skærmbilleder, gengiver appen dem ved hjælp af den samme proces.

Datakaldflow i lærredapps

Dataopkald fra lærredsapps sender data til tabelformede datakilder ved at bruge forbindelser over OData-protokollen. OData-anmodninger flyder til back-end-lagene for at kontakte målet datakilde og hente data til klienten eller overføre data til datakilde. Handlingsbaserede connectors, der aktiverer API'er, fungerer på samme måde.

En forståelse af, hvordan OData- og API-anmodninger sendes rundt i lærredsapps, kan hjælpe dig med at optimere ydeevnen i lærredsappen og dine backend-datakilder.

I dette afsnit får du at vide, hvordan datakald bevæger sig i lærredapps med forskellige datakildetyper.

Datakaldflow med onlinedatakilder

I følgende diagram vises, hvordan en typisk dataanmodning i en lærredapp (på venstre side) bevæger sig på serverbaserede lag og opretter forbindelse til måldatakilden (på højre side) og derefter returnerer dataene til klienten.

Hvert lag i ovenstående diagram kan udføres hurtigt, eller der kan være problemer med belastning under behandling af anmodningen. I mange apps kan der især være to tegn på væsentlige belastninger:

• Backenddatakilde: Under behandling af anmodningen.

• Klient: Mens du sender anmodningen – eller mens du manipulerer de modtagne data i heaphukommelsen og udfører de tilknyttede JavaScript-funktioner for at behandle data, der skal vises på skærmene.

Datakaldflow med datagateway i det lokale miljø

Hvis en lærredapp opretter forbindelse til en datakilde i det lokale miljø, f.eks. SQL Server, skal du have et andet lag, der kaldes datagateway i det lokale miljø. Denne gateway er obligatorisk for at få adgang til datakilder i det lokale miljø. Den sørger for at konvertere OData-protokolforespørgsler til SQL DML-sætninger (Data Manipulation Language).

I følgende diagram vises, hvor og hvordan datagatewayen i det lokale miljø oprettes for at behandle dataanmodninger.

Hvis appen bruger en datakilde i det lokale miljø, vil placeringen og specifikationen af datagatewayen også påvirke ydeevnen for datakald.

Flow for dataopkald med Microsoft Dataverse

Når du bruger Microsoft Dataverse som datakilde, går dataanmodninger direkte til miljøforekomsten uden at passere gennem Azure API Management. Ydeevnen for datakald er derfor meget hurtigere i forhold til de øvrige datakilder. Appen er som standard tilsluttet Microsoft Dataverse, når du opretter en ny lærredapp.

Nu, hvor du forstår dette grundlæggende koncept for, hvordan datakald bevæger sig rundt, kan du gå mere i detaljer og gennemse din apps ydeevne. Kort fortalt kan ydeevnebelastning ske på alle lag – fra klient, API Management, connector, datagateway i det lokale miljø eller backenddatakilderne.

Måle ydeevne

Power Apps-overvågningsværktøj

Mens du kan bruge browserens udviklerværktøjer til at se ydeevnen, kan Power Apps undersæts med opkald i overvågningsværktøjet til dem, der er Power Apps.

Power Apps-overvågningsværktøjet kan hjælpe dig med at spore, hvad der faktisk sendes til datakilde og tidsstempler for, hvornår anmodninger sendes og svar kommer fra serveren.

Du kan lære mere om overvågningsværktøjet i denne artikel: Fejlretning af lærredsapps med Monitor.

Måling af hukommelsesbelastning på klienten

For at se hukommelsesforbrug grafisk kan du bruge udviklerværktøjerne til din browser til at profilere hukommelsen. Det hjælper dig med at visualisere heapstørrelse, dokumenter, noder og lyttefunktioner. Profilér appens ydeevne ved hjælp af en browser som beskrevet i Oversigt over Microsoft Edge-udviklerværktøjer (Chromium). Kontrollér de scenarier, der overskrider hukommelsesgrænsen for JS-heap'en. Flere oplysninger: Løse hukommelsesproblemer

Næste trin

Små datanyttedata

Se også

Fejlfinding i forbindelse med Power Apps

Bemærk

Kan du fortælle os om dine sprogpræferencer for dokumentation? Tag en kort undersøgelse. (bemærk, at denne undersøgelse er på engelsk)

Undersøgelsen tager ca. syv minutter. Der indsamles ingen personlige data (erklæring om beskyttelse af personlige oplysninger).