Vanliga prestandaproblem och lösningar för arbetsyteappar

Du kan skapa arbetsyteappar med olika matriser av datakällor. Välj datakälla och en anslutning beroende på de affärsbehov och scenarier som appen är utformad för. För företagsappar är Microsoft Dataverse den datakälla som rekommenderas eftersom det ger flera prestandafördelar. För appar med några få transaktioner kan du gå med andra tillgängliga datakällor i miljön.

För prestandaöverväganden för en app, tänk på antalet användare som kommer att använda appen när den har publicerats; volymen av skapa, hämta, uppdatera och ta bort (CRUD) transaktioner; typen av datainteraktioner; geografisk åtkomst; och vilken typ av enheter användare har.

I den här artikeln lär du dig bland annat om några av de vanligaste prestandaproblemen som kan göra att appar körs långsamt och hur du löser dem. Med hjälp av den här informationen kan du förbättra app-prestanda med din affärsplan och tillväxt i åtanke.

Vi börjar med några vanliga prestandaproblem som sker oavsett vilken anslutning som används. I de senare avsnitten lär du dig mer om prestandaproblem och lösningar som är mer specifika för olika anslutningarna.

Innan du börjar ska du se till att du förstår körningsfaserna och datasamtalsflödet för arbetsyteappar. Dessutom är möjliga källorna till långsamma prestanda för arbetsyteappar beskriver vanliga fallgropar som du kan undvika när du utformar eller uppdaterar arbetsyteappar.

Stora datauppsättningar som går långsamt att läsa in på olika plattformar

Prestanda för en app kan variera när stora uppsättningar data läses in på olika plattformar som iOS eller Android. Detta beror på olika begränsningar för nätverksbegäran på varje plattform. Antalet tillåtna samtidiga nätverksförfrågningar kan till exempel vara olika för plattformar. Den här skillnaden kan ha en stor påverkan på databelastningen på stora datauppsättningar.

Vi rekommenderar att du endast läser in de data som behöver visas direkt på skärmen. För andra data, sidnumrera och cachelagra dina data. Mer information: Tips och metodtips för att förbättra prestanda i arbetsyteappar

För många kolumner som har hämtats

Vi rekommenderar att du endast väljer de kolumner som behövs för appen. Om du lägger till fler eller alla kolumner datakälla hämtas all data i kolumnen. Den här åtgärden resulterar i ett stort antal nätverkssamtal och ger därför hög minnesanvändning i klientenheten. Det här problemet kan påverka användare med mobila enheter ännu mer om bandbredden är begränsad, eller om en enhet har begränsat minne, eller en äldre processor.

Om du till exempel använder Dataverse som datakälla för appen ska du kontrollera att du har aktiverat funktionen Explicit kolumnval. Med den här Power Apps-funktionen kan du endast begränsa hämtningen av data för kolumnerna som används i appen.

För att aktivera den explicita kolumnvalsfunktionen på arbetsyteappen, gå till Inställningar > Kommande funktioner > Förhandsversion och aktivera sedan växlingsknappen Explicit kolumnval.

Webbläsare som inte stöds eller som är gamla

Användare som använder webbläsare som inte stöds eller äldre webbläsare kan få prestandaproblem. Se till att användarna bara använder de webbläsare som stöds för att köra arbetsyteappar.

Långsam prestanda på grund av geografiskt distans

Den geografiska platsen för miljön och datakällans närhet till användarna påverkar prestanda.

Vi rekommenderar att din miljö placeras nära användarna. Även om Power Apps använder Azure Content Delivery Network för innehåll, kan datasamtal fortfarande hämta data från datakälla. Datakälla ligger på en annan geografisk plats kan det påverka appens prestanda negativt.

Överdrivet geografiskt avstånd påverkar prestanda i olika formulär, t.ex. för miljön, reducerat genomflöde, lägre bandbredd och färre skador.

Lista över tillåtna har inte konfigurerats

Kontrollera att de tjänstadresser som krävs inte har blockerats eller att de har lagts till i tillåtslistan för brandväggen. En fullständig lista över alla tjänstadresser som krävs för Power Apps går du till Obligatoriska tjänster.

Användning av icke-delegerbara funktioner och begränsning för datarad för icke-delegerbara frågor

Delegerbara funktioner delegerar databearbetningen datakälla, vilket minimerar belastningen vid klientsidan. Om det inte är möjligt att delegera dataradsgränsen för icke-delegerbara frågor kan du begränsa antalet rader som returneras från en serverbaserad anslutning.

Användning av icke-delegerbara funktioner, och begränsning för förlegade datarader för icke-delegerbara frågor gör dataöverföringen extra användbar. Detta resulterar i manipulering av mottagen data till JS heap på klientsidan. Se till att du alltid kan använda delegerbara funktionerna för appen när det är tillgängligt, samt begränsningen för datarad för icke-delegerbara frågor.

Mer information: Använd delegering, Översikt delegering

Justering av händelsebehoven på OnStart

OnStart-händelsen körs när programmet läses in. Om du anropar stora mängder data med funktionerna i appens egenskap OnStart kommer appen att läsas in sakta. En skärm med starkt beroende av kontroller och värden som definieras på en annan skärm påverkas av långsam skärmnavigering.

I följande avsnitt beskrivs några av de vanligaste problemen i dessa situationer.

Stort antal samtal i OnStart-händelsen som gör att appen börjar långsamt

På ett företag kan en volym datasamtal till en central datakälla leda till att servern får en flaskhals eller en resurs.

Använd cachemekanism och optimera datasamtal. En enskild app kan användas av många användare, vilket resulterar i många datasamtal per användare som når serverns slutpunkter. Dessa dataanrop kan vara en plats där buteljering eller begränsning kan inträffa.

Svarstid på OnStart-händelsen på grund av tunga skript

Tunga skript på OnStart är ett av de vanligaste misstagen när du utformar arbetsyteappar. Beslutsfattare bör bara få de data som krävs för att appen ska starta.

Optimera formeln i en OnStart-händelse. Flytta till exempel vissa funktioner till egenskapen OnVisible i stället. På så sätt kan du låta appen starta snabbt, och andra steg kan fortsätta medan appen öppnas.

Mer information: Optimera egenskapen OnStart

Dricks

Vi rekommenderar att du använder egenskapen App.StartScreen eftersom den förenklar appstart och ökar appens prestanda.

Minnesbelastning på klientsidan

Det är viktigt att kontrollera minnesanvändningen av en appar eftersom appen för de flesta tillfällen körs på mobila enheter. Minnesundantag i heap är den troligaste orsaken till att en mobilapp kraschar eller låser sig på vissa enheter.

JavaScript-heap (JS) kan påverka belastningen på grund av skript som körs på klientsidan för att lägga till, sammanfoga, filtrera, sortera eller gruppera kolumner. I de flesta fall kan ett minnesfel i heapen på klienten utlösa en krasch eller leda till att appen kraschar.

När du använder data från källorna som Dataverse eller SQL Server, kan du använda objektet Vy för att säkerställa att anslutning, filtrering, gruppering eller sortering sker på serversidan i stället för på klientsidan. Den här metoden minskar belastningen på klienterna när det gäller skript för sådana åtgärder.

Om klienttunga åtgärder som JOIN eller Gruppera efter inträffade på klientsidan med en datamängd med 2 000 poster eller mer, kommer objekten i högen att öka, vilket leder till att du träffar taket.

Med utvecklarverktygen för de flesta webbläsare kan du profilera minnet. Det skulle visualisera hög storlek, dokument, noder och lyssnare. Profilera appens prestanda med hjälp av en webbläsare enligt beskrivningen i Microsoft Edge (Chromium) översikt över utvecklarverktyg. Kontrollera scenarierna som överskrider minneströskeln för JS heap. Mer information: Åtgärda minnesproblem

Att tänka på när du använder anslutningsprogrammet SQL Server

Du kan använda anslutningsprogrammet SQL Server för Power Apps att ansluta till SQL Server lokalt eller Azure SQL Database. I det här avsnittet beskrivs vanliga prestandarelaterade problem och lösningar för att använda den här kopplingen för en app. Mer information: Anslut till SQL Server från Power Apps, Skapa en arbetsyteapp från Azure SQL Database

Anteckning

I det här avsnittet refereras anslutningsprogrammet SQL Server till prestandaproblem och lösningar, men de flesta av rekommendationerna gäller även när du använder databastyper—t.ex. MySQL eller PostgreSQL—som datakälla.

Vi tar en titt på vanliga prestandaproblem och lösningar när du använder anslutningsprogrammet SQL Server för arbetsyteappar.

N+1 fråga

Gallerier som genererade för många förfrågningar till servrar orsakade problem med N+1-frågor. Problemet N+1 fråga r ett av de vanligaste problemen när du använder kontrollen Galleri.

Du kan undvika problemet genom att vyobjekt i SQL-backend eller ändra scenarierna för användargränssnittet.

Tabellsökning i stället för indexavläsning

En app kan gå långsammare om funktionerna som används av appen kör frågor i databasen vilket resulterar i tabellsökning i stället för indexsökning. Mer information: Tips, tabellsökning och indexsökning

För att lösa sådana problem använder du StartsWith istället för IN i formeln. Med en SQL-datakälla resulterar operatorn StartsWith i en indexsökning, men operatorn IN resulterar i en index- eller tabellsökning.

Långsamma frågor

Profilera och finjustera långsamma frågor och index i SQL-databasen. Om det exempelvis finns en formel som hämtar vissa data med fallande ordning (DESC) i en viss kolumn ska sorteringskolumnen ha ett index med fallande ordning. Med indexnyckeln skapas stigande ordning (ASC) som standard.

Du kan också kontrollera URL-adressen för databegäranden. Följande databegäran kan exempelvis kodavsnitt (partiell OData-anrop) uppmanar SQL att returnera 500 poster som matchar kolumnen till Värde och ordning efter ID i fallande ordning.

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

På så sätt blir det lättare att förstå indexkraven när det gäller sådana begäransvillkor. I det här exemplet bör ID-kolumnen ha ett index med fallande ordning för att utföra frågan snabbare.

Kontrollera körningsplanen för långsamma frågor och se om det finns någon tabell eller indexsökning. Övervaka eventuella onödiga kostnader för Nyckeluppslag i körningsplanen.

Mer information:

• Övervaka och finjustera prestanda
• Övervaka prestanda med hjälp av frågearkivet
• Översikt över utökade händelser

Information om databasresurs

Se till datakälla—SQL Database—inte har några resurstvister som processorflaskhals, I/O-konflikt, minnesbelastning eller tempDB. Sök även efter lås, väntetid, deadlock och tidsgräns för frågor.

Dricks

Använd automatisk justering för insikter i möjliga insikter om potentiella problem med frågeprestanda, rekommenderade lösningar och att automatiskt åtgärda identifierade problem.

Fet klient eller för stora förfrågningar

För en app som kör åtgärder för åtgärderna Gruppera efter, Filtrera efter eller JOIN på klientsidan används processor och minnesresurser från klientenheterna. Beroende på datastorleken kan dessa åtgärder ta längre skripttid på klientsidan, vilket ökar JS heap storleken på klienten. När du använder lokal datakälla ökar detta problem eftersom varje uppslagsdatasamtal reser till datakällan via datagateway.

I sådana situationer kan du använda objektet Vy i SQL-databasen för åtgärder för Gruppera efter, Filtrera efter eller JOIN. Vyer kan använda vissa kolumner och ta bort onödiga kolumner med stora datatyper som NVARCHAR(MAX), VARCHAR(MAX) och VARBINARY(MAX).

Dricks

Den här metoden hjälper också till att lösa N+1 frågeproblem.

Datastorlek som överförs till klienten

Som standard visar en arbetsyteapp data med hjälp av tabellerna eller vyer från de tillgängliga databasobjekten. Om du hämtar alla kolumner från en tabell kan det resultera i ett långsamt svar, särskilt när du använder stora datatyper som NVARCHAR(MAX).

Det tar lång tid att överföra stora mängder data till klienter. Den här överföringen resulterar också i mer skripttid när det finns stora mängder data i JS heap på klientsidan enligt beskrivningen ovan i den här artikeln.

För att minska storleken på data som överförs till klienten, använd vyer med de specifika kolumner som krävs för appen och se till att uttryckligt kolumnval är aktiverat, som beskrivs tidigare i denna artikel.

Att tänka på när det gäller SQL Server lokal

Prestanda för arbetsyteappar som använder anslutningsprogrammet SQL Server med en lokal datagateway kan påverkas på olika sätt. I det här avsnittet beskrivs vanliga prestandaproblem och lösningar som är specifika för lokal databaskälla.

Ej felfri lokal datagateway

Organisationer kan definiera flera noder för lokal datagateways. Även om en av noderna inte kan nås, kommer dataförfrågningar till den ej felfria noden inte att returnera inom en acceptabel tidsram, eller så kan de orsaka "oåtkomliga" felmeddelanden efter att ha väntat ett tag.

Se till lokal alla datagatewaynoder är felfria och konfigurerade med ett minimum av nätverkskonfigurering mellan noderna och SQL-instansen.

Placering av en lokal datagateway

Datagateway kräver nätverkssamtal för lokal datakällor för att tolka OData-begäran. Datagatewayen måste till exempel förstå datatabellschemat för att översätta OData-förfrågningar till SQL-dataspråk (DML). Extra belastning läggs till om datagatewayen har konfigurerats på en separat plats med hög nätverkskapacitet mellan datagatewayen och SQL-instansen.

I en företagsmiljö rekommenderas det att ha ett skalbart datagateway-kluster när förfrågningar om data kan förväntas. Kontrollera hur många anslutningar som har upprättats mellan noderna för datagateway och SQL-instansen.

Genom att kontrollera de samtidiga anslutningarna i en lokal datagateway eller i en SQL-instans kan din organisation identifiera var datagatewayen behöver skalas ut och med hur många noder.

Skalbarhet för datagateway

Om du förväntar dig att få tillgång till en stor mängd data från lokal datagateway kan bara en nod i lokal datagatewayen bli en flaskhals för att hantera så stora mängder förfrågningar.

En enskild nod i lokal till en datagateway kan vara tillräcklig för att hantera 200 eller färre samtidiga anslutningar. Om alla de här samtidiga anslutningarna kör frågor aktivt får andra förfrågningar vänta på en tillgänglig anslutning.

Information om hur du säkerställer att din lokal datagateway skalas i enlighet med mängden data och förfrågningar går du till Övervaka och optimera prestanda för lokal datagateway.

Saker som är specifika för Azure SQL Database

Arbetsyteappar kan ansluta till Azure SQL Database via anslutningsprogrammet SQL Server. En vanlig orsak till prestandaproblem när du använder Azure SQL Database väljer fel nivå för dina affärskrav.

Azure SQL Database finns på olika servicenivåer med funktioner som fungerar för att matcha olika affärskrav. Mer information om nivåer finns i dokumentationen för Azure SQL Database.

Om du begär olika data kan resurserna på den nivå du väljer bli för begränsade när tröskelvärdet nås. En sådan begränsning gör att nästa uppsättning frågor prestanda förs.

Kontrollera servicenivån i Azure SQL Database. En lägre nivå kan ha vissa begränsningar. Ur ett prestandaperspektiv är det viktigt med processor, I/O-genomflöde och svarstid. Därför rekommenderar vi att du regelbundet kontrollerar SQL-databasens prestanda och kontrollera om resursanvändningen överskrider tröskelvärdet. Till exempel när lokal SQL Server anger tröskelvärdet för processoranvändning till cirka 75 %.

Att tänka på när du använder anslutningsprogrammet SharePoint

Du kan använda SharePoint kopplingen för att skapa appar med hjälp av data från Microsoft-listor. Du kan också skapa appar direkt från listvyn. Vi tar en titt på vanliga prestandaproblem och lösningar när du använder SharePoint datakälla med arbetsyteappar.

För många dynamiska uppslagskolumner

SharePoint har stöd för olika datatyper inklusive dynamiska uppslag, t.ex. Person, Grupp och Beräknade. Om en lista definierar för många dynamiska kolumner tar det längre tid att ändra dessa dynamiska kolumner i SharePoint innan data returneras till klienten som kör appen.

Överutnyttja inte de dynamiska uppslagskolumnerna i SharePoint. Det här överutnyttjandet kan leda till undvikande och extra belastning i SharePoint sida för manipulation av data. Du kan till exempel använda statisk kolumn för att behålla e-postalias, eller namn på personerna i stället.

Bildkolumn och bifogad fil

Storleken på en bild och bifogad fil kan ge ett långsamt svar när klienten hämtas.

Granska listan och se till att endast de kolumner som krävs har definierats. Antalet kolumner i listan påverkar prestanda för databegäranden. Denna effekt beror på de matchade posterna eller att posterna upp till de definierade dataradgränserna hämtas och skickas tillbaka till klienten med alla kolumner definierade i listan—oavsett om appen använder dem alla eller inte.

Om du bara vill fråga de kolumner som används av appen aktiverar du den explicita kolumnvalfunktionen som beskrivs tidigare i denna artikel.

Stora listor

Om det finns en stor lista med hundratusentals poster kan du överväga att dela upp listan eller dela upp listan i flera listor baserat på parametrar som kategorier, datum och tid.

Dina data kan till exempel lagras i olika listor varje år eller månad. Sedan kan du designa appen så att en användare kan välja ett tidsfönster för att hämta data inom det intervallet.

I en kontrollerad miljö har prestandatestet visat att prestanda för OData-förfrågningar mot Microsoft-listor eller SharePoint är starkt relaterat till antalet kolumner i listan och antalet rader som hämtas ( begränsas av dataradsgränsen för icke-delegerade frågor). Lägre antal kolumner och lägre inställningar för dataradsbegränsningar kan göra att appen kan fungera bättre.

I den verkliga världen är emellertid apparna utformade för att uppfylla vissa affärskrav. Det är kanske inte snabbt eller enkelt att minska dataradsgränsen eller antalet kolumner i en lista. Du bör dock övervaka OData-begäran på klientsidan och justera gränsen för datarad för frågor som inte kan delegeras och antalet kolumner i en lista.

Att tänka på när du använder Dataverse som datakälla

När du använder Microsoft Dataverse som datakälla skickas databegäran till miljöinstansen direkt, utan att skicka via Azure API Management. Mer information: Datasamtalsflöden när du ansluter till Microsoft Dataverse

Dricks

När anpassade tabeller används i Dataverse kan det krävas ytterligare säkerhetskonfiguration för att användarna ska kunna visa posterna med appar. Mer information: Säkerhetskoncept i Dataverse, Konfigurera användarsäkerhet för resurser i en miljö och Säkerhetsroller och privilegier

En arbetsyteapp som är ansluten till Dataverse kan utföra långsamt om det kör klienttungt skript som Filtrera efter eller JOIN på klientsidan istället för på serversidan.

Använd Dataverse-vyer när det är möjligt. En vy med de villkor som krävs för koppling eller filter hjälper dig att minska risken för att använda en hel tabell. Om du till exempel behöver sammanfoga tabeller och filtrera data för dem kan du definiera en vy genom att sammanfoga dem och endast definiera de kolumner du behöver. Använd sedan den här vyn i appen som skapar den här vyn vid serversidan för koppling/filter-operation istället för på klientsidan. Med den här metoden minskar inte bara de extra åtgärderna utan även dataöverföringen. Information om hur du redigerar filter och sorteringsvillkor finns i Redigera filtervillkor.

Att tänka på när du använder Excel-anslutningsprogrammet

Med Excel-anslutningsprogrammet kan du ansluta från en app till data i en tabell i en Excel-fil. Det här anslutningsprogrammet har begränsningar jämfört med andra datakällor—till exempel begränsade delegerbara funktioner—som gör att arbetsyteappen kan läsa in data från tabellen endast upp till 2 000 poster. Om du vill läsa in fler än 2 000 poster delar du dina data i olika datatabeller som andra datakällor.

Vi tar en titt på vanliga prestandaproblem och lösningar när du använder Excel som datakälla för arbetsyteappar och hur man löser dem.

För många datatabeller och stor datastorlek

Långsamhet i appen kan upplevas när den använder Excel-fil med för många datatabeller, eller datatabeller med storlek på data över flera kolumner. Excel-filen är inte en relationsdatabas eller en datakälla som innehåller delegerbara funktioner. Power Apps måste ladda data från de definierade datatabellerna först, och använder sedan funktioner som t.ex Filter, Sort, JOIN, Group By och Search.

För många datatabeller, med högt antal rader och kolumner, påverkar appens prestanda och klientsidans resultat eftersom varje datatabell måste hanteras inom JS heap. Den här effekten leder också till att appen förbrukar mer minne på klientsidan.

För att säkerställa att appen inte påverkas av detta problem, definierar du endast de kolumner som behövs i datatabellen i en Excel-fil.

Tunga transaktioner

Excel är inte ett relationsdatabassystem. Alla ändringar från en app hanteras i Excel på samma sätt som en användare ändrar data i en Excel-fil. Om appen har ett stort antal läsåtgärder, men färre CRUD-åtgärder kan den prestera bra. Men om appen gör flera transaktioner kan det påverka appens prestanda negativt.

Det finns inget specifikt tröskelvärde för antalet transaktioner eftersom det även beror på data som ändras. Flera andra aspekter påverkar också appens prestanda, till exempel nätverket eller användarens enhet.

Om du har skrivskyddade data kan du importera sådana data lokalt i appen i stället för att läsa in dem från datakälla. För företagsappar kan du använda datakällor som Dataverse, SQL Server eller SharePoint i stället.

Filstorlek

Du kan välja bland en mängd olika alternativ för molnlagring med varierande—eller konfigurerbar—lagringskapacitet för Excel-filen. Men en enda stor Excel-fil med alla tabeller definierade i en fil lägger till ett extra tillägg för appen när du hämtar filen och läser in data vid klientsidan.

I stället för att använda en stor fil delar du upp data i flera Excel-filer med minimidatatabeller. Anslut sedan endast till varje fil när du behöver den. På så sätt går det att läsa in data från datatabellerna, vilket minskar belastningen på många tabeller eller den stora datauppsättningen.

Sökväg

Datakällans geografiska läge och avståndet från klientplatser kan resultera i en flaskhals för prestanda för appen och inducera nätverksfördröjning. Den här effekten kan förstärks med en mobilklient med begränsad bandbredd för anslutning.

Det är bättre att hålla filen nära dina slutanvändare (eller de flesta slutanvändarnaför global publik) så att filen kan laddas ner snabbt.

Nästa steg

Tips och metodtips för att förbättra prestanda för arbetsyteappar

Se även

Förstå körningsfaser och datasamtalsflöde i arbetsyteappar
Vanliga källor till långsamma prestanda för en arbetsyteapp
Vanliga problem och lösningar för Power Apps
Felsöker startproblem för Power Apps

Anteckning

Kan du berätta om dina inställningar för dokumentationsspråk? Svara i en kort undersökning. (observera att undersökningen är på engelska)

Undersökningen tar ungefär sju minuter. Inga personuppgifter samlas in (sekretesspolicy).