Almindelige problemer med og løsninger til ydeevne i lærredapp

Du kan oprette lærredapps ved hjælp af en række forskellige datakilder. Vælg datakilde og connector baseret på de forretningsbehov og scenarier, du vil designe appen til. Til virksomhedsapps er Microsoft Dataverse den anbefalede datakilde, da den giver flere fordele i forhold til ydeevne. I forbindelse med apps med få transaktioner kan du vælge at bruge alle andre tilgængelige datakilder i dit miljø.

Hvis du vil have overvejelser om ydeevne i en app, skal du overveje antallet af brugere, der skal bruge appen, når den er blevet udgivet. Antallet af oprettelses-, hente, opdatere og slette (CRUD)-transaktioner. Typen af datainteraktioner. Geografisk adgang og den type enheder, brugerne har.

I denne artikel får du mere at vide om nogle af de mest almindelige ydeevneproblemer, der kan få lærredapps til at køre langsomt, og hvordan du kan løse dem. Disse oplysninger hjælper dig med at forbedre appens ydeevne med din virksomhedsplan og vækst for øje.

Vi starter med nogle af de almindelige ydeevneproblemer, der kan opstå, uanset hvilken connector der bruges. I senere afsnit får du mere at vide om ydeevneproblemer og løsninger, der er specifikke for en lang række connectorer.

Før du begynder, skal du sikre dig, at du forstår faserne til udførelse af lærredapps og dataopkaldsflow. Du kan også læse Almindelige kilder til langsom ydeevne for en lærredapp for at få mere at vide om almindelige faldgruber, du kan undgå, når du designer eller opdaterer lærredapps.

Store datasæt, der indlæses langsomt på forskellige platforme

Ydeevnen for en app kan variere, når du indlæser store datasæt på forskellige platforme, f.eks. iOS eller Android. Denne variation sker på grund af forskellige begrænsninger i netværksanmodninger på de enkelte platforme. Antallet af tilladte samtidige netværksanmodninger kan f.eks. være forskelligt på de enkelte platforme. Denne forskel kan have stor indflydelse på dataindlæsningstiden for store datasæt.

Det anbefales, at du kun indlæser de data, du skal se på skærmen med det samme. I forbindelse med andre data skal du sideinddele og cachelagre dataene. Flere oplysninger: Tip og bedste praksis til forbedring af ydeevnen i lærredapps

Der er hentet for mange kolonner

Det anbefales, at du kun vælger de kolonner, der er nødvendige for appen. Hvis du tilføjer flere (eller alle) kolonner fra datakilden, downloades alle data i kolonnerne. Handlingen medfører et stort antal opkald på netværket og dermed et højt hukommelsesforbrug på klientenheden. Dette problem kan påvirke brugere med mobilenheder endnu mere, hvis netværksbåndbredden er begrænset, eller hvis en enhed har begrænset hukommelse eller en ældre processor.

Hvis du f.eks. bruger Dataverse som datakilde for din app, skal du kontrollere, at du har aktiveret funktionen explicit column selection. Denne funktion gør det muligt for Power Apps at begrænse hentning af data til kun de kolonner, der bruges i appen.

Hvis du vil slå funktionen til explicit column selection til i lærredappen, skal du gå til Indstillinger > Kommende funktioner > Forhåndsversion og aktivere til/fra-feltet Eksplicit kolonnevalg.

Ikke-understøttede eller ældre browsere

Brugere, der anvender ikke-understøttede eller ældre browsere, kan opleve problemer med ydeevnen. Sørg for, at brugerne kun bruger understøttede browsere til at køre lærredapps.

Langsom ydeevne på grund af geografisk afstand

Den geografiske placering af miljøet og afstanden mellem datakilden og slutbrugerne kan påvirke ydeevnen.

Det anbefales, at miljøet placeres tæt på brugerne. Power Apps bruger Azure Content Delivery Network til indhold, men dataopkald henter stadig dataene fra datakilden. En datakilde, der er placeret et andet geografisk sted, kan have en negativ indvirkning på appens ydeevne.

For stor geografisk afstand påvirker ydeevnen på forskellige måder, f.eks. ventetid, reduceret gennemløb, lavere båndbredde eller pakketab.

Listen over tilladte blev ikke konfigureret

Kontrollér, at de påkrævede URL-adresser til tjenester ikke er blevet blokeret, eller at de er føjet til din firewalls liste over tilladte tjenester. Du kan se en fuldstændig liste over alle de URL-adresser til tjenester, der skal være tilladt for Power Apps, ved at gå til Påkrævede tjenester.

Brug af funktioner, der ikke kan delegeres, og upassende begrænsninger af datarækker for forespørgsler, der ikke kan delegeres

Funktioner, der kan delegeres, delegerer behandlingen af data til datakilden for at minimere belastningen på klientsiden. Når det ikke er muligt at delegere data, kan du begrænse grænsen for datarækker for forespørgsler, der ikke kan delegeres, så antallet af rækker, der returneres fra en serverbaseret forbindelse, forbliver optimalt.

Brugen af funktioner, der ikke kan delegeres, og upassende datarækkegrænser for forespørgsler, der ikke kan delegeres, medfører ekstra belastning i forbindelse med dataoverførsel. Denne belastning resulterer i manipulation af de modtagne data til JS-heap på klientsiden. Sørg for at bruge funktioner, der kan delegeres, for appen, når de er tilgængelige, og at bruge den optimale datarækkegrænse for forespørgsler, der ikke kan delegeres.

Flere oplysninger: Brug delegering, Oversigt over delegering

OnStart-hændelse skal finjusteres

OnStart-hændelsen kører, når programmet indlæses. Hvis du kalder store mængder data ved hjælp af funktionerne i egenskaben OnStart for appen, indlæses appen langsomt. En skærm, der har stor afhængighed til kontrolelementer og værdier, der er defineret på et andet skærmbillede, medfører langsom skærmnavigation.

I følgende afsnit beskrives nogle af de mest almindelige problemer, der opstår i disse situationer.

Stort antal kald i OnStart-hændelser medfører, at appen starter langsomt

I en virksomhed kan mængden af datakald til en central datakilde skabe flaskehalse eller ressourcekonflikter.

Brug en cachemekanisme til at optimere datakald. En enkelt app kan bruges af mange brugere, hvilket resulterer i mange datakald pr. bruger til serverens slutpunkter. Disse datakald kan være det sted, hvor flaskehalsen eller begrænsningen opstår.

Ventetid ved OnStart-hændelse på grund af tunge scripts

Tunge scripts ved OnStart-hændelse er en af de mest almindelige fejl, når du designer lærredapps. Du skal kun bruge de data, der er nødvendige, for at appen kan starte.

Optimer formlen i en OnStart-hændelse. Du kan f.eks. flytte nogle funktioner til egenskaben OnVisible i stedet. På denne måde kan du lade appen starte hurtigt, og andre trin kan fortsætte, mens appen åbnes.

Flere oplysninger: Optimere egenskaben OnStart

Hukommelsesbelastning på klientsiden

Det er vigtigt at kontrollere hukommelsesforbruget i en lærredapp, da appen oftest kører på mobilenheder. Undtagelser for hukommelsen i heap'en er den mest sandsynlige årsag til, at en lærredapp går ned eller fryser ("hænger") på visse enheder.

En JS-heap (JavaScript) kan ramme grænsen på grund af tunge scripter, der kører på klientsiden for at tilføje, sammenkæde, filtrere, sortere eller gruppere kolonner. I de fleste tilfælde kan en undtagelse for "ikke mere hukommelse" ved heap'en i en klient medføre, at appen går ned eller hænger.

Når du bruger data fra kilder som f.eks. Dataverse eller SQL Server kan du bruge et Visning-objekt til at sikre, at der opstår sammenkædning, filtrering, gruppering eller sortering på serversiden i stedet for på klientsiden. Denne fremgangsmåde reducerer belastningen på klienten ved scripting for sådanne handlinger.

Hvis tunge klienthandlinger som JOIN eller Gruppér efter er sket på klientsiden med et datasæt, der har 2000 poster eller flere, øges objekterne i heap'en, hvilket vil resultere i, at hukommelsesgrænserne overskrides.

Med udviklerværktøjer for de fleste browsere kan du 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

Overvejelser om ydeevne i forbindelse med SQL Server-connector

Du kan bruge SQL Server-connectoren til Power Apps til at oprette forbindelse til SQL Server i det lokale miljø eller Azure SQL Database. I dette afsnit beskrives almindelige ydeevnerelaterede problemer og løsninger til brug af denne connector til en lærredapp. Flere oplysninger: Oprette forbindelse til SQL Server fra Power Apps, Oprette en lærredapp fra Azure SQL Database

Lad os se på de almindelige ydeevneproblemer og -løsninger, når du bruger SQL Server-connectoren til lærredapps.

N+1-forespørgsel

Gallerier, der genererer for mange forespørgsler til servere, forårsager problemer med N+1-forespørgsel. Problemer med N+1-forespørgsler er et af de mest almindelige problemer, når du bruger kontrolelementet Galleri.

Hvis du vil undgå problemet, skal du bruge visningsobjekter i SQL-back-end eller ændre scenarierne på brugergrænsefladen.

Tabelscanning i stedet for indekssøgning

En app kører muligvis langsommere, hvis de funktioner, der bruges af appen, kører forespørgsler i databasen, hvilket resulterer i tabelscanninger i stedet for indekssøgning. Flere oplysninger: Tips, tabelscanning og indekssøgning

Hvis du vil løse sådanne problemer, skal du bruge StartsWith i stedet for IN i formlen. Når du bruger en SQL-datakilde, resulterer operatoren StartsWith i en indekssøgning, men operatoren IN resulterer i en indeks- eller tabelscanning.

Langsomme forespørgsler

Du kan profilerere og finjustere langsomme forespørgsler og indekser i SQL-databasen. Hvis f.eks. en formel henter bestemte data i faldende rækkefølge (DESC) i en bestemt kolonne, skal den pågældende sorteringskolonne have et indeks med faldende rækkefølge. Indeksnøglen opretter som standard stigende rækkefølge (ASC).

Du kan også kontrollere URL-adressen til dataanmodninger. I følgende kodestykke med en dataanmodning (delvist OData-kald) bliver SQL f.eks. bedt om at returnere 500 poster, der matcher kolonnen, til Værdi, og rækkefølge efter Id, i faldende rækkefølge.

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

Det gør det nemmere at forstå indekskravene, når lignende anmodningsbetingelser afdækkes. Hvis kolonnen Id i dette eksempel f.eks. har et indeks med faldende rækkefølge, udføres forespørgslen hurtigere.

Kontrollér udførelsesplanen for langsomme forespørgsler for at se, om der findes en tabel- eller indeksscanning. Overvåg eventuelle ekstra omkostninger ved nøgleopslag i udførelsesplanen.

Flere oplysninger:

• Overvåge og finjustere for ydeevne
• Overvåge ydeevnen ved hjælp af forespørgselslageret
• Oversigt over udvidede hændelser

Ressourcekonflikter i database

Sørg for, datakilden – SQL-databasen – ikke har ressourcekonflikter, f.eks. processerflaskehalse, I/O-konflikt, hukommelsesbelastning eller tempDB-konflikt. Kontrollér også, om der er timeout for låse, ventetider, deadlock og forespørgsler.

Tunge klientanmodninger eller overdrevne anmodninger

En app, der kører handlingerne Gruppér efter, Filtrer efter eller JOIN på klientsiden, bruger processor- og hukommelsesressourcer fra klientenheder. Afhængigt af datastørrelsen kan det tage længere scriptingtid at udføre disse handlinger på klientsiden, og dermed øges størrelsen på JS-heap på klienten. Dette problem forstærkes for en datakilde i det lokale miljø, fordi hvert enkelt kald efter opslagsdata skal omkring datagatewayen til datakilden.

I sådanne situationer skal du bruge objektet Vis i SQL-databasen til handlingerne Gruppér efter, Filtrer efter eller JOIN. Visningerne kan bruge bestemte kolonner og fjerne unødvendige kolonner med store datatyper, f.eks. NVARCHAR(MAX), VARCHAR(MAX) og VARBINARY(MAX).

Datastørrelse, der overføres til klienten

Som standard viser en lærredapp data ved hjælp af tabellerne eller visningerne fra de tilgængelige databaseobjekter. Hvis du henter alle kolonner fra en tabel, kan det resultere i langsom svar, især når du bruger store datatyper, f.eks. NVARCHAR(MAX).

Det tager tid at overføre store mængder data til klienter. Denne overførsel resulterer også i mere scriptingtid, når der er store mængder data i JS-heap'en på klientsiden, som beskrevet tidligere i denne artikel.

Hvis du vil reducere størrelsen på de data, der overføres til klienten, skal du bruge visninger med de specifikke kolonner, der kræves til appen, og sikre, at dette eksplicitte kolonnevalg er aktiveret, som beskrevet tidligere i denne artikel.

Overvejelser, der er specifikke for SQL Server i det lokale miljø

Ydeevnen for en lærredapps, der bruger SQL Server-connectoren med en datagateway i det lokale miljø, kan blive berørt på mange måder. Dette afsnit indeholder de almindelige ydeevneproblemer og -løsninger, der er specifikke for brug af en databasekilde i det lokale miljø.

Usund datagateway i det lokale miljø

Organisationer kan definere flere noder for datagateways i det lokale miljø. Selvom der ikke kan oprettes forbindelse til en af noderne, returnerer dataanmodninger til den usunde node ikke resultatet inden for en acceptabel tidsramme, eller der vises fejlmeddelelser om manglende forbindelse efter et stykke tid.

Sørg for, at alle datagatewaynoder i det lokale miljø er sunde og konfigureret med en minimal netværksventetid mellem noderne og SQL-forekomsten.

Placering af datagatewayen i det lokale miljø

En datagateway kræver netværkskald til datakilder i det lokale miljø for at fortolke OData-anmodningerne. Datagatewayen skal f.eks. forstå datatabelskemaet for at oversætte OData-forespørgsler til DML-sætninger (SQL Data Manipulation Language). Der tilføjes ekstra belastning, når datagatewayen er konfigureret på en separat placering med høj netværksventetid mellem datagatewayen og SQL-forekomsten.

I et virksomhedsmiljø anbefales det at have en skalerbar datagatewayklynge, når der forventes tunge forespørgsler om data. Kontrollér, hvor mange forbindelser der er oprettet mellem datagatewaynoderne og SQL-forekomsten.

Ved at kontrollere de samtidige forbindelser i en datagateway i det lokale miljø eller på en SQL-forekomst kan din organisation identificere, hvor datagatewayen skal skaleres ud, og med hvor mange noder.

Skalerbarhed af datagateway

Hvis du forventer at få adgang til en stor mængde data fra datagatewayen i det lokale miljø, kan blot en enkelt node i datagatewayen i det lokale miljø blive en flaskehals, når du håndterer så stort et antal forespørgsler.

En enkelt node i datagatewayen i det lokale miljø kan være tilstrækkelig til at håndtere 200 eller færre samtidige forbindelser. Men hvis alle disse samtidige forbindelser kører forespørgsler aktivt, kan andre forespørgsler ende med at vente på en tilgængelig forbindelse.

Du kan finde oplysninger om, hvordan du sikrer, at datagatewayen i det lokale miljø skaleres i overensstemmelse med mængden af data og anmodninger, ved at gå til Overvåge og optimere ydeevne for datagateways i det lokale miljø.

Overvejelser, der er specifikke for Azure SQL Database

Lærredapps kan oprette forbindelse til Azure SQL Database ved hjælp af SQL Server-connectoren. En almindelig årsag til ydeevneproblemer, når du bruger Azure SQL Database, er at det forkerte niveau vælges til dine forretningskrav.

Azure SQL Database er tilgængelig på forskellige serviceniveauer med diverse funktioner, der gør det muligt at opfylde forskellige forretningskrav. Du kan finde flere oplysninger om niveauer ved at gå til dokumentationen til Azure SQL Database.

Når der anmodes om omfattende datamængder, aktiveres ressourcerne på det niveau, du vælger, muligvis, når tærskelværdien rammes. Denne type begrænsning svækker ydeevnen for det næste sæt forespørgsler.

Kontrollér serviceniveauet for Azure SQL Database. Et lavere niveau vil medføre visse begrænsninger. Fra et ydeevneperspektiv er CPU, I/O-gennemløb og ventetid vigtige faktorer. Vi anbefaler derfor, at du jævnligt kontrollerer SQL-databasens ydeevne, og kontrollér, om ressourceforbruget overskrider grænsen. SQL Server i det lokale miljø sætter f.eks. normalt grænsen for CPU-forbrug til omkring 75 %.

Overvejelser om ydeevne i forbindelse med SharePoint-connector

Du kan bruge SharePoint-connector til at oprette apps ved hjælp af data fra Microsoft Lister. Du kan også oprette lærredapps direkte fra listevisningen. Lad os se på de almindelige ydeevneproblemer og -løsninger, når du bruger en SharePoint-datakilde med lærredapps.

For mange dynamiske opslagskolonner

SharePoint understøtter forskellige datatyper, herunder dynamiske opslag, f.eks. Person, Gruppe og Beregnet. Hvis en liste definerer for mange dynamiske kolonner, tager det længere tid at manipulere disse dynamiske kolonner i SharePoint, før der returneres data til den klient, der kører lærredappen.

Brug ikke for mange dynamiske opslagskolonner i SharePoint. Dette overforbrug kan resultere i unødvendig og ekstra belastning på SharePoint-siden ved manipulation af data. Du kan f.eks. bruge statiske kolonner til at opbevare mailaliaser eller navne på personer i stedet.

Billedkolonne og vedhæftet fil

Størrelsen på et billede og en vedhæftet fil kan være medvirkende årsag til et langsomt svar under hentning til klienten.

Gennemse listen, og kontrollér, at det kun er nødvendige kolonner, der er defineret. Antallet af kolonner på listen påvirker ydeevnen af dataanmodningerne. Dette skyldes de matchede poster, eller at posterne op til de definerede grænser for datarækken er hentet og sendt tilbage til klienten med alle de kolonner, der er defineret på listen – også selvom appen ikke bruger dem alle.

Hvis du kun vil forespørge om de kolonner, der bruges af appen, skal du aktivere funktionen til valg af eksplicitte kolonner, som beskrevet tidligere i denne artikel.

Store lister

Hvis du har en stor liste med hundrede tusinder af poster, kan du overveje at partitionere listen eller at opdele den i flere lister baseret på parametre som kategorier eller dato og klokkeslæt.

Dataene kan f.eks. gemmes på forskellige lister på års- eller månedsbasis. I dette tilfælde kan du designe appen, så en bruger kan vælge et tidsvindue og hente dataene inden for det pågældende interval.

I et kontrolleret miljø har ydeevne-benchmark vist, at ydeevnen af OData-forespørgsler i forhold til Microsoft Lister eller SharePoint er yderst relateret til antallet af kolonner på listen og antallet af rækker, der hentes (begrænset af grænsen for datarækken for forespørgsler, der ikke kan uddelegeres). Hvis du har et lavere antal kolonner og en lavere indstilling af datarækkegrænsen, kan det betyde, at en lærredapp fungerer bedre.

I den virkelige verden er apps dog udviklet til at imødekomme visse forretningskrav. Det er muligvis ikke en hurtig eller nem løsning at reducere datarækkegrænsen eller antallet af kolonner på en liste. Vi anbefaler dog, at du overvåger OData-anmodningerne på klientsiden og justerer datarækkegrænsen for forespørgsler, der ikke kan delegeres, og antallet af kolonner på listen.

Overvejelser om ydeevne ved brug af Dataverse som datakilde

Når du bruger Microsoft Dataverse som datakilde, går dataanmodninger direkte til miljøforekomsten uden at passere gennem Azure API Management. Flere oplysninger: Flow for dataopkald under oprettelse af forbindelse til Microsoft Dataverse

En lærredapp, der tilsluttet Dataverse, udfører måske langsomt, hvis den kører tunge klientscripts, f.eks. Filtrer efter eller JOIN på klientsiden i stedet for på serversiden.

Brug Dataverse-visninger, når det er muligt. En visning med de påkrævede kriterier for sammenkædning eller filtrering er med til at reducere belastningen ved at bruge en hel tabel. Hvis du f.eks. skal sammenkæde tabeller og filtrere deres data, kan du definere en visning ved at sammenkæde dem og kun definere de kolonner, du skal bruge. Derefter kan du bruge denne visning i din app, som opretter denne belastning på serversiden, til sammenkædning/filtrering i stedet for på klientsiden. Denne metode reducerer ikke kun de ekstra handlinger, men også datatransmissionen. Gå til Rediger filterkriterier, hvis du vil have oplysninger om redigering af filter- og sorteringskriterier.

Overvejelser om ydeevne i forbindelse med Excel-connector

Excel-connectoren leverer forbindelse fra en lærredapp til dataene i en tabel i en Excel-fil. Denne connector har begrænsninger i forhold til andre datakilder, f.eks. begrænsede funktioner, der kan delegeres, så lærredappen kun kan indlæse data fra tabellen på op til 2.000 poster. Hvis du vil indlæse mere end 2.000 poster, skal du partitionere dataene i forskellige datatabeller som andre datakilder.

Lad os se på de almindelige ydeevneproblemer, når du bruger Excel som datakilde for lærredapps, og hvordan du kan løse dem.

For mange datatabeller og stor datastørrelse

En app kører måske langsom, når den bruger en Excel-fil, der har for mange datatabeller, eller datatabeller, der indeholder en stor mængde data over flere kolonner. En Excel-fil er ikke en relationsdatabase eller en datakilde, der indeholder funktioner, som kan delegeres. Power Apps skal først indlæse data fra de definerede datatabeller og derefter bruge funktioner som Filter, Sortér, JOIN, Gruppe efter og Søg.

Hvis du har for mange datatabeller med mange rækker og kolonner, påvirker det appens ydeevne og belastningen på klientsiden, da de enkelte datatabeller skal manipuleres i JS-heap'en. Denne effekt medfører også, at appen forbruger mere klienthukommelse.

Hvis du vil sikre dig, at din app ikke påvirkes af dette problem, skal du kun definere de kolonner, du skal bruge, i datatabellen i en Excel-fil.

Tunge transaktioner

Excel er ikke et system med relationsdatabaser. Eventuelle ændringer fra en app administreres af Excel på samme måde, som hvis en bruger ændrer data i en Excel-fil. Hvis appen har et højt antal læsninger, men færre CRUD-handlinger, kan den muligvis fungere godt. Men hvis appen foretager tunge transaktioner, kan det have en negativ indvirkning på appens ydeevne.

Der er ingen specifik tærskelværdi for antallet af transaktioner, da det også afhænger af de data, der manipuleres. Flere andre aspekter påvirker også appens ydeevne, f.eks. belastning på netværket eller brugerens enhed.

Hvis du har skrivebeskyttede data, kan du importere disse data til appen lokalt i stedet for at indlæse dem fra datakilden. I forbindelse med virksomhedsapps skal du bruge datakilder som Dataverse, SQL Server eller SharePoint i stedet.

Filstørrelse

Du kan vælge mellem en lang række muligheder for skylager med varierende – eller konfigurerbar – lagerkapacitet til Excel-filen. Men hvis du har en enkelt stor Excel-fil, hvor alle tabeller er defineret i den pågældende fil, betyder det ekstra belastning for appen, mens den henter filen og læser de data, der skal indlæses på klientsiden.

I stedet for at bruge én stor fil, kan du opdele dataene i flere Excel-filer med minimale datatabeller. Opret kun forbindelse til de enkelte filer, når du har brug for det. På denne måde sker indlæsningen af dataene fra datatabellen i fragmenter, hvilket reducerer belastningen ved at have mange tabeller eller et stort datasæt.

Filplacering

Den geografiske placering af datakilden og afstanden til klientplaceringerne kan resultere i en ydeevneflaskehals for appen og medføre ventetid på netværket. Denne effekt kan blive forstærket, når en mobilklient har begrænset båndbredde til forbindelsen.

Det anbefales at have filen i nærheden af dine brugere (eller de fleste af brugerne, hvis du har en global målgruppe), så filen hurtigt kan hentes.

Næste trin

Tip og bedste praksis til forbedring af ydeevnen i lærredapps

Se også

Om kørselsfaser for lærredapps og datakaldflow
Almindelige kilder til langsom ydeevne for en lærredapp
Almindelige problemer og løsninger for Power Apps
Fejlfinding af startproblemer for Power Apps