Vanlige ytelsesproblemer og løsninger for lerretsapper

Du kan bygge lerretsapper med ulike alternativer for datakilder. Velg riktig datakilde og en kontakt avhengig av forretningsbehovene og scenariene appen er utformet for. For virksomhetsapper anbefales Microsoft Dataverse som datakilde fordi det gir flere ytelsesfordeler. For apper med noen få transaksjoner kan du gå til alle andre tilgjengelige datakilder i miljøet.

Av hensyn til ytelsen til en app bør du vurdere antall brukere som skal bruke appen når den er publisert, volumet for transaksjoner for oppretting, henting, oppdatering og sletting (CRUD), datasamhandlingstypen, geografisk tilgang og hvilke typer enheter brukere har.

I denne artikkelen lærer du om noen av de vanligste ytelsesproblemene som kan gjøre at lerretsapper kjører tregt, og hvordan du løser dem. Denne informasjonen vil hjelpe deg med å forbedre appytelsen med tanke på forretningsplan og vekst.

Vi begynner med noen av de vanlige ytelsesproblemene som oppstår uavhengig av om koblingen brukes. I de senere delene lærer du om ytelsesproblemer og løsninger som er mer spesifikke for ulike koblinger.

Før du begynner, må du sørge for at du forstår utførelsesfasene for lerretsapp og datakallflyten. Les også Vanlige kilder til treg ytelse for en lerretsapp for å lære om vanlige fallgruver du kan unngå når du utformer eller oppdaterer lerretsapper.

Store datasett lastes langsomt på forskjellige plattformer

Ytelsen til en app kan variere ved lasting av store datasett på ulike plattformer, for eksempel iOS eller Android. Denne variasjonen skjer på grunn av forskjellige begrensninger for nettverksforespørsler for hver plattform. Antall tillatte samtidige nettverksforespørsler kan for eksempel variere fra plattform til plattform. Denne forskjellen kan ha stor innvirkning på datainnlastingstiden for store datasett.

Vi anbefaler at du bare laster inn dataene du umiddelbart trenger å vise på skjermen. For andre data kan du paginere og hurtigbufre dataene. Mer informasjon: Tips og gode fremgangsmåter for å forbedre ytelsen til lerretsapper

For mange kolonner hentet

Det anbefales at du bare velger de nødvendige kolonnene for appen. Hvis du legger til flere eller alle kolonnene fra datakilden, lastes alle dataene i kolonnene ned. Denne handlingen fører til et stort antall nettverkstilkoblingskall og derfor høy bruk av minne i klientenheten. Dette problemet kan påvirke brukere med mobilenheter enda mer hvis nettverksbåndbredden er begrenset, eller hvis en enhet har begrenset minne eller en eldre prosessor.

Hvis du for eksempel bruker Dataverse som datakilde for appen, må du kontrollere at du har aktivert funksjonen Eksplisitt kolonnevalg. Denne funksjonen gjør at Power Apps kan begrense datahentingen til bare kolonnene som brukes i appen.

Hvis du vil aktivere funksjonen for eksplisitt kolonnevalg i lerrstsappen, går du til Innstillinger > Kommende funksjoner > Forhåndsversjon, og deretter slår du på veksleknappen Eksplisitt kolonnevalg.

Nettlesere som ikke støttes, eller eldre nettlesere

Brukere som bruker weblesere som ikke støttes eller eldre weblesere, kan oppleve ytelsesproblemer. Kontroller at brukerne bare bruker støttede nettlesere for kjøring av lerretsapper.

Treg ytelse på grunn av geografisk avstand

Geografisk plassering av miljøet og avstanden til datakilden fra brukerne påvirker ytelsen.

Vi anbefaler at miljøet befinner seg i nærheten av brukere. Selv om Power Apps bruker Azure Content Delivery Network til innhold, henter datakall fortsatt dataene fra datakilden. En datakilde som befinner seg på en annen geografisk plassering, kan ha negativ innvirkning på ytelsen til appen.

Store geografiske avstander påvirker ytelsen på forskjellige måter, for eksempel latens, redusert gjennomstrømming, lavere båndbredde og pakketap.

Tillatelsesliste er ikke konfigurert

Kontroller at nødvendige nettadresser for tjenester ikke er blokkert, eller at de er lagt til i tillatelseslisten for brannmuren. For en fullstendig liste over alle URL-tjenesteadresser som må være tillatt for Power Apps, kan du gå til Nødvendige tjenester.

Bruk av funksjoner som ikke kan delegeres, og feil dataradgrense for spørringer som ikke kan delegeres

Delegerbare funksjoner delegerer behandlingen av data til datakilden og minimerer administrasjonen på klientsiden. Når delegering ikke er mulig, kan du begrense dataradgrensen for spørringer som ikke kan delegeres, slik at antall rader som returneres fra en serverbasert tilkobling, forblir optimalt.

Bruk av funksjoner som ikke kan delegeres, og feil dataradgrenser for spørringer som ikke kan delegeres, betyr ekstra belastning på dataoverføring. Denne belastningen fører til endringer i de mottatte dataene i JS heap på klientsiden. Sørg for at du bruker delegerbare funksjoner i appen når det er tilgjengelig, og den optimale dataradgrensen for spørringer som ikke kan delegeres.

Mer informasjon: Bruk delegering, Delegeringsoversikt

OnStart-hendelse trenger finjustering

OnStart-hendelsen kjører når programmet lastes inn. Hvis du kaller store mengder data ved hjelp av funksjonene i OnStart-egenskapen i appen, laster appen langsomt inn. En skjerm med tung avhengighet av kontroller og verdier som er definert i en annen skjerm, vil bli påvirket av treg skjermnavigering.

Avsnittene nedenfor beskriver noen av de vanligste problemene som oppstår i disse situasjonene.

Stort antall kall i OnStart-hendelse som fører til at appen starter tregt

I en virksomhet kan volumet av datakall til en sentral datakilde øke flaskehalsen på serveren eller antallet ressurstvister.

Bruk en hurtigbuffermekanisme til å optimalisere datakall. En enkelt app kan brukes av mange brukere, noe som fører til mange datasamtaler per bruker som når frem til serverens endepunkter. Disse datakallene kan være et sted der flaskehalsen eller begrensning kan skje.

Ventetid for OnStart-hendelse på grunn av tunge skript

Tunge skript på en OnStart-hendelse er en av de vanligste feilene når du utformer lerretsapper. Du bør bare hente dataene som kreves for at appen skal starte.

Optimaliser formelen i en OnStart-hendelse. Flytt for eksempel noen funksjoner til OnVisible-egenskapen i stedet. På denne måten kan du la appen starte raskt, og andre trinn kan fortsette mens appen åpnes.

Mer informasjon: Optimalisere OnStart-egenskapen

Tips

Vi anbefaler at du bruker App.StartScreen-egenskapen siden den forenkler applanseringen og øker appens ytelse.

Minnetrykk på klientsiden

Det er viktig å kontrollere minnebruken for en lerretsapp fordi appen som regel kjører på mobilenheter. Minneunntak i heapen er den mest sannsynlige årsaken bak en lerretsapp som krasjer eller fryser (henger) på bestemte enheter.

En JavaScript-heap (JS) kan nå grensen fordi tunge skript kjører på klientsiden for å legge til, sammenkoble, filtrere, sortere eller gruppere kolonner. I de fleste tilfeller kan et tomt for minne-unntak i heapen i en klient utløse at appen krasjer eller henger.

Når du bruker data fra kilder som, for eksempel Dataverse eller SQL Server, kan du bruke et Visning-objekt for å sikre at kobling, filtrering, gruppering eller sortering forekommer på serversiden i stedet for på klientsiden. Denne metoden reduserer klientkostnadene for skript for slike handlinger.

Hvis klienttunge operasjoner som Slå sammen eller Grupper etter har skjedd på klientsiden med et datasett som har 2000 oppføringer eller mer, vil objektene i heapen øke, noe som fører til at minnegrensen overskrides.

Utviklerverktøy for de fleste nettlesere gjør det mulig å profilere minnet. 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

Ytelseshensyn for SQL Server-koblingen

Du kan bruke SQL Server-koblingen for Power Apps til å koble til SQL Server lokalt eller Azure SQL Database. Denne delen beskriver vanlige ytelsesrelaterte problemer og løsninger for bruk av denne koblingen for en lerretsapp. Mer informasjon: Koble til SQL Server fra Power Apps, Opprette en lerretsapp fra Azure SQL Database

Obs!

Selv om denne delen refererer til en SQL Server-kobling for ytelsesproblemer og -løsninger, gjelder de fleste av anbefalingene også når du bruker en databasetype som datakilde, for eksempel MySQL eller PostgreSQL.

La oss se på de vanlige ytelsesproblemene og løsningene når du bruker SQL Server-koblingen for lerretsapper.

N+1-spørring

Gallerier som genererer for mange forespørsler til servere, forårsaker problemer med N+1-spørring. Problemet med N+1-spørring er et av de vanligste problemene når du bruker Galleri -kontrollen.

Du kan unngå problemet ved å bruke visningsobjekter i SQL-serverdelen eller endre scenarier for brukergrensesnittet.

Tabellskanning i stedet for indekssøk

En app kan redusere hastigheten hvis funksjonene som brukes av appen, kjører spørringer i databasen, noe som medfører tabellskanninger i stedet for indekssøk. Mer informasjon: Tips, tabellskanning og søking i indekser

For å løse slike problemer bruker du StartsWith i stedet for IN i formelen. Med en SQL-datakilde fører StartsWith-operatoren til et indekssøk, men IN-operatoren fører til en indeks- eller tabellskanning.

Trege spørringer

Du kan profilere og justere langsomme spørringer og indekser i SQL-databasen. Hvis det for eksempel finnes en formel som henter data med synkende rekkefølge (DESC) i en bestemt kolonne, må denne sorteringskolonnen ha en indeks med synkende rekkefølge. Indeksnøkkelen oppretter stigende rekkefølge (ASC) som standard.

Du kan også kontrollere URL-adressen til dataforespørsler. Følgende dataforespørselssnutt (delvis OData-kall) ber for eksempel SQL om å returnere 500 oppføringer som samsvarer kolonnen med Verdi og sorterer etter ID i synkende rekkefølge.

Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500

Dette bidrar til å forstå indekskrav for å overholde lignende forespørselsbetingelser. I dette eksemplet, hvis ID-kolonnen har en indeks med synkende rekkefølge, utføres spørringen raskere.

Kontroller kjøreplanen for langsomme spørringer for å se om det finnes tabell- eller indekssøk. Overvåk eventuelle omfattende kostnader ved nøkkeloppslag i utførelsesplanen.

Mer informasjon:

• Overvåking og justering for ytelse
• Overvåke ytelse ved hjelp av spørringslageret
• Oversikt over utvidede hendelser

Ressurstvist i database

Kontroller at datakilden – SQL Database – ikke har ressurstvister, for eksempel flaskehalser i prosessor, I/U-tvist, minnetrykk eller tempDB-tvist. Du kan også se etter låsinger, ventinger, vranglås og tidsavbrudd for spørringer.

Tips

Bruk automatisk justering for å få innsikt i potensielle problemer med spørringsytelsen, anbefalte løsninger og til automatisk å løse de identifiserte problemene.

Tykk klient eller for mange forespørsler

En app som kjører Grupper etter, Filtrer etter eller Slå sammen-operasjoner på klientsiden, bruker prosessor- og minneressurser fra klientenhetene. Avhengig av datastørrelsen kan det ta lengre tid før skripting utføres på klientsiden, noe som øker JS heap-størrelsen på klienten. Dette problemet øker for en lokal datakilde fordi hvert oppslagsdatakall går til datakilden gjennom datagatewayen.

I slike situasjoner kan du bruke Vis-objektet i SQL Database for Grupper etter-, Filtrer etter- eller Slå sammen-operasjoner. Visninger kan bruke selektive kolonner og fjerne unødvendige kolonner med store datatyper, for eksempel NVARCHAR(MAX), VARCHAR(MAX) og VARBINARY(MAX).

Tips

Denne metoden bidrar også til å løse problemet med N+1-spørringen.

Datastørrelse overført til klienten

Som standard viser en lerretsapp data ved hjelp av tabellene eller visningene fra de tilgjengelige databaseobjektene. Henting av alle kolonner fra en tabell kan føre til tregt svar, spesielt når store datatyper brukes, for eksempel NVARCHAR(MAX).

Overføring av store mengder data til klienter tar tid. Overføringen fører også til mer skripttid når det er store mengder data i JS-heapen på klientsiden, som beskrevet tidligere i denne artikkelen.

Hvis du vil redusere størrelsen på data som overføres til klienten, bruker du visninger med de bestemte kolonnene som kreves for appen, og kontrollerer at eksplisitt kolonnevalg er aktivert, som beskrevet tidligere i denne artikkelen.

Vurderinger som er spesifikke for lokal SQL Server

Ytelsen til en lerretsapp som bruker SQL Server-koblingen med en lokal datagateway, kan bli påvirket på forskjellige måter. Denne delen viser vanlige ytelsesproblemer og løsninger som er spesifikke for bruk av en lokal databasekilde.

Usunn lokal datagateway

Organisasjoner kan definere flere noder for lokale datagatewayer. Selv om en av nodene ikke kan nås, vil ikke dataforespørsler til den usunne noden returnere resultatet innen rimelig tid, eller føre til "kan ikke nås"-feilmeldinger etter å ha ventet en stund.

Kontroller at alle noder for den lokale datagatewayen er sunne og konfigurert med minimum nettverkslatens mellom nodene og SQL-forekomsten.

Plassering til lokal datagateway

En datagateway krever nettverkskall til lokale datakilder for å tolke OData-forespørslene. Datagatewayen må for eksempel forstå datatabellskjemaet for å kunne oversette OData-forespørsler til SQL DML-setninger (datamanipuleringsspråk). Ekstra kostnader legges til når datagatewayen konfigureres på et separat sted med høy nettverkslatens mellom datagatewayen og SQL-forekomsten.

I et virksomhetsmiljø anbefales det å ha en skalerbar datagatewayklynge når tunge dataforespørsler er forventet. Kontroller hvor mange tilkoblinger som er opprettet mellom datagatewaynodene og SQL-forekomsten.

Ved å kontrollere de samtidige tilkoblingene i en lokal datagateway eller i en SQL-forekomst kan organisasjonen avgjøre tidspunktet når dataportalen må skaleres ut, og med hvor mange noder.

Skalerbarhet for datagateway

Hvis du forventer å få tilgang til et stort datavolum fra den lokale datagatewayen, kan bare én enkelt node i den lokale datagatewayen bli til en flaskehals når den skal håndtere et så stort antall forespørsler.

Én enkelt node i den lokale datagatewayen kan være tilstrekkelig til å håndtere opptil 200 samtidige tilkoblinger. Hvis alle disse samtidige tilkoblingene kjører spørringer aktivt, vil andre forespørsler ende opp med å vente på en tilgjengelig tilkobling.

Hvis du vil ha informasjon om hvordan du sikrer at den lokale datagatewayen skaleres i samsvar med volumet av data og forespørsler, kan du gå til Overvåk og optimaliser ytelse for lokal datagateway.

Vurderinger som er spesifikke for Azure SQL Database

Lerretsapper kan koble til Azure SQL Database ved hjelp av SQL Server-koblingen. En vanlig årsak til ytelsesproblemer når du bruker Azure SQL Database, er å velge feil lag for dine forretningskrav.

Azure SQL Database er tilgjengelig i forskjellige servicenivåer, med ulike funksjoner for å samsvare forskjellige forretningskrav. For mer informasjon om nivåer kan du gå til Azure SQL Database-dokumentasjonen.

Ved tunge dataforespørsler kan ressursene på det valgte nivået bli avgrenset når terskelverdien blir nådd. En slik begrensning kompromitterer ytelsen til det neste spørringssettet.

Kontroller tjenestenivået i Azure SQL Database. Det nederste nivået har noen begrensninger. Fra et ytelsesperspektiv er CPU, I/U-gjennomstrømming og latens viktig. Derfor anbefaler vi at du kontrollerer ytelsen til SQL Database regelmessig og også kontrollerer om ressursbruken overskrider terskelverdien. Eksempel: Den lokale SQL Server setter vanligvis terskelverdien for CPU-bruk til rundt 75 %.

Ytelseshensyn for SharePoint-koblingen

Du kan bruke SharePoint-koblingen til å opprette apper ved hjelp av data fra Microsoft Lister. Du kan også opprette lerretsapper direkte fra listevisningen. La oss se på de vanlige ytelsesproblemene og løsningene når du bruker en SharePoint-datakilde med lerretsapper.

For mange dynamiske oppslagskolonner

SharePoint støtter ulike datatyper, inkludert dynamiske oppslag, for eksempel Person, Gruppe og Beregnet. Hvis en liste definerer for mange dynamiske kolonner, tar det lengre tid å manipulere disse dynamiske kolonnene i SharePoint før dataene returneres til klienten som kjører lerretsappen.

Ikke bruk for mange dynamiske oppslagskolonner i SharePoint. Dette overforbruket kan føre til unngåelige og ekstra kostander på SharePoint-siden for manipulering av data. Du kan i stedet bruke statiske kolonner til å beholde e-postaliaser eller navn på personer.

Bildekolonne og vedlegg

Størrelsen på et bilde og den vedlagte filen kan gi et langsomt svar under henting til klienten.

Se gjennom listen, og kontroller at bare de nødvendige kolonnene er definert. Antall kolonner i listen påvirker ytelsen til dataforespørsler. Denne effekten skyldes at de matchede oppføringene, eller oppføringene opp til de definerte dataradgrensene, hentes og overføres tilbake til klienten med alle kolonnene definert i listen, enten appen bruker alle dataene eller ikke.

For å spørre bare kolonnene som brukes av appen, aktiverer du funksjonen for eksplisitt kolonnevalg, som beskrevet tidligere i denne artikkelen.

Store lister

Hvis du har en stor liste med flere hundre tusen oppføringer, kan du vurdere å partisjonere listen eller dele den opp i flere lister basert på parametere, for eksempel kategorier eller dato og klokkeslett.

Dataene kan for eksempel lagres i ulike lister årlig eller månedlig. I slike tilfeller kan du utforme appen slik at en bruker kan velge et tidsvindu og hente dataene innenfor dette området.

I et kontrollert miljø har ytelsestestesten vist at ytelsen til OData-forespørsler mot Microsoft Lister eller SharePoint er svært relatert til antall kolonner i listen og antall rader som hentes (begrenset av dataradgrensen for spørringer som ikke kan delegeres). Et lavere antall kolonner og en lavere innstilling for dataradgrensen kan få en lerretsapp til å yte bedre.

I den virkelige verden er apper imidlertid utformet for å oppfylle visse forretningskrav. Det er ikke sikkert at det er raskt eller enkelt å redusere dataradgrensen eller antall kolonner i en liste. Det anbefales imidlertid å overvåke OData-forespørsler fra klientsiden og justere dataradgrensen for spørringer som ikke kan delegeres, og antall kolonner i listen.

Ytelseshensyn ved bruk av Dataverse som datakilde

Når du bruker Microsoft Dataverse som datakilden, går dataforespørsler direkte til miljøforekomsten uten å gå gjennom Azure API Management. Mer informasjon: Dataoppkallsflyt ved tilkobling til Microsoft Dataverse

Tips

Når egendefinerte tabeller brukes i Dataverse, kan det hende at ytterligere sikkerhetskonfigurasjon kreves for at brukere skal kunne vise oppføringene med lerretsapper. Mer informasjon: Sikkerhetskonsepteri Dataverse, Konfigurer brukersikkerhet for ressurser i et miljø og Sikkerhetsroller og rettigheter

En lerretsapp som er koblet til Dataverse, kan gå tregt hvis den kjører klienttunge skript, for eksempel Filtrer etter eller Slå sammen på klientsiden i stedet for på serversiden.

Bruk Dataverse-visninger når dette er mulig. En visning med de nødvendige koblings- eller filtervilkårene bidrar til å redusere kostnadene for bruk av en hel tabell. Hvis du for eksempel må koble tabeller og filtrere dataene i dem, kan du definere en visning ved å koble dem sammen og bare definere kolonnene du trenger. Deretter kan du bruke denne visningen i appen, som oppretter denne ekstra kostnaden på serversiden for kobling/filter-operasjonen, i stedet for på klientsiden. Denne metoden reduserer ikke bare de ekstra operasjonene, men også dataoverføring. Hvis du vil ha informasjon om redigering av filter- og sorteringsvilkår, kan du gå til Rediger filtervilkår.

Ytelseshensyn for Excel-koblingen

Excel-koblingen gir tilkobling fra en lerretsapp til dataene i en tabell i en Excel-fil. Denne koblingen har begrensninger sammenlignet med andre datakilder — for eksempel begrensede delegerbare funksjoner—, som begrenser lerretsappen fra å laste inn data fra tabellen til opptil 2000 oppføringer. Hvis du vil laste inn mer enn 2000 oppføringer, partisjonerer du dataene i forskjellige datatabeller som andre datakilder.

La oss se på de vanlige ytelsesproblemene med Excel som datakilde for lerretsapper, og hvordan du løser dem.

For mange datatabeller og stor datastørrelse

Treghet i appen kan oppleves når den bruker en Excel-fil med for mange datatabeller, eller datatabeller som har en stor størrelse av data over flere kolonner. Excel-filen er ikke en relasjonsdatabase, eller en datakilde som inneholder delegerbare funksjoner. Power Apps må først laste inn data fra de definerte datatabellene, og deretter bruke funksjoner som Filter, Sorter, Slå sammen, Grupper etter og Søk.

For mange datatabeller med mange rader og kolonner påvirker appytelsen og administrasjonen på klientsiden fordi hver datatabell må manipuleres i JS-heapen. Denne effekten fører også til at appen bruker mer minne på klientsiden.

For å sikre at appen din ikke blir påvirket av dette problemet, definerer du bare de nødvendige kolonnene i datatabellen i en Excel-fil.

Tunge transaksjoner

Excel er ikke et relasjonsdatabasesystem. Alle endringer fra en app administreres av Excel på samme måte som når en bruker endrer data i en Excel-fil. Hvis appen har et stort antall lesinger, men færre CRUD-operasjoner, kan det gi gode resultater. Hvis appen imidlertid gjennomfører tunge transaksjoner, kan dette ha negativ innvirkning på ytelsen til appen.

Det finnes ingen spesifikk terskelverdi for antall transaksjoner, siden dette også avhenger av dataene som manipuleres. Flere andre aspekter har også innvirkning på appytelsen, for eksempel nettverkskostnadene eller brukerens enhet.

Hvis du har skrivebeskyttede data, kan du importere slike data til appen lokalt i stedet for å laste dem inn fra datakilden. For virksomhetsapper kan du bruke datakilder som Dataverse, SQL Server eller SharePoint i stedet.

Filstørrelse

Du kan velge blant en rekke ulike alternativer for skylagring med varierende eller konfigurerbar lagringskapasitet for Excel-filen. Én enkelt stor Excel-fil med alle tabeller definert i filen, medfører imidlertid en ekstra byrde for appen når du laster ned filen og leser dataene som skal lastes inn på klientsiden.

I stedet for å bruke én stor fil bør du dele opp dataene i flere Excel-filer med minimumsdatatabeller. Deretter kobler du bare til hver fil når du trenger den. På denne måten skjer lasting av dataene fra datatabellen i fragmenter og reduserer belastningen for mange tabeller eller store datasett.

Filplassering

Geografisk plassering for datakilde, og avstand fra klientlokasjonene kan føre til en ytelsesflaskehals for appen og føre til nettverkslatens. Denne effekten kan bli forsterket med en mobil klient som har begrenset båndbredde for tilkobling.

Det er bedre å holde filen nær sluttbrukerne (eller de fleste sluttbrukerne, for en global målgruppe), slik at filen kan lastes ned raskt.

Neste trinn

Tips og gode fremgangsmåter for å forbedre ytelsen til lerretsapper

Se også

Forstå kjørefaser og datakallflyter for lerretsapper
Vanlige kilder til treg ytelse for en lerretsapp
Vanlige problemer og løsninger for Power Apps
Feilsøk oppstartsproblemer 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).