Veelvoorkomende prestatieproblemen en oplossingen voor canvas-apps

Artikel
03/16/2023

U kunt canvas-apps bouwen met een grote verscheidenheid aan gegevensbronnen. Kies de gegevensbron en connector op basis van de zakelijke behoeften en scenario's waarvoor u de app ontwerpt. Voor zakelijke apps is Microsoft Dataverse de aanbevolen gegevensbron, omdat deze verschillende prestatievoordelen biedt. Voor apps met een paar transacties kunt u kiezen voor andere beschikbare gegevensbronnen in uw omgeving.

Denk bij prestatieoverwegingen van een app na over het aantal gebruikers dat de app gebruikt wanneer deze is gepubliceerd, het volume van CRUD-transacties (maken, ophalen, bijwerken en verwijderen), het type gegevensinteracties, geografische toegang en het soort apparaten dat gebruikers hebben.

In dit artikel leest u over enkele van de meest voorkomende prestatieproblemen die ervoor kunnen zorgen dat canvas-apps traag werken en hoe u deze kunt oplossen. Deze informatie helpt u de prestaties van apps te verbeteren met het oog op uw bedrijfsplan en groei.

We beginnen met enkele veelvoorkomende prestatieproblemen, ongeacht de connector die wordt gebruikt. In latere secties leest u over prestatieproblemen en oplossingen die specifieker zijn voor de verschillende connectoren.

Voordat u begint, moet u ervoor zorgen dat u de uitvoeringsfasen van canvas-apps en de stroom van gegevensoproepen begrijpt. Lees ook Veelvoorkomende bronnen van trage prestaties voor een canvas-app voor informatie over veelvoorkomende valkuilen die u kunt vermijden tijdens het ontwerpen of bijwerken van canvas-apps.

Grote gegevenssets worden langzaam geladen op verschillende platforms

De prestaties van een app kunnen variëren bij het laden van grote sets gegevens op verschillende platforms, zoals iOS of Android. Deze variatie treedt op vanwege verschillende beperkingen voor netwerkverzoeken op elk platform. Het aantal toegestane gelijktijdige netwerkverzoeken kan bijvoorbeeld per platform verschillen. Dit verschil kan een grote invloed hebben op de laadtijd van gegevens voor grote gegevenssets.

We raden u aan om alleen de gegevens te laden die u onmiddellijk op het scherm wilt weergeven. Voor andere gegevens pagineert u uw gegevens en plaatst u ze in de cache. Meer informatie: Tips en best practices om de prestaties van canvas-apps te verbeteren

Te veel kolommen opgehaald

Het wordt aanbevolen om alleen de kolommen te selecteren die nodig zijn voor de app. Als u meer of alle kolommen toevoegt uit de gegevensbron, worden alle gegevens in de kolommen gedownload. Deze actie resulteert in een groot aantal netwerkoverheadaanroepen en dus een hoog geheugengebruik op het clientapparaat. Dit probleem kan nog meer gevolgen hebben voor gebruikers met mobiele apparaten als de netwerkbandbreedte beperkt is of als een apparaat beperkt geheugen of een oudere processor heeft.

Als u bijvoorbeeld Dataverse als gegevensbron voor uw app gebruikt, zorgt u ervoor dat u de functie Expliciete kolomselectie hebt ingeschakeld. Deze functie maakt het mogelijk dat Power Apps het ophalen van gegevens beperkt tot alleen de kolommen die in de app worden gebruikt.

Om de functie voor expliciete kolomselectie in de canvas-app in te schakelen, gaat u naar Instellingen > Komende functies > Preview en schakelt u vervolgens schakelaar Expliciete kolomselectie in.

Niet-ondersteunde of verouderde browsers

Gebruikers die niet-ondersteunde of verouderde browsers gebruiken, kunnen prestatieproblemen ondervinden. Zorg ervoor dat de gebruikers alleen gebruikmaken van ondersteunde browsers voor het uitvoeren van canvas-apps.

Trage prestaties vanwege geografische afstand

De geografische locatie van de omgeving en de afstand van de gegevensbron tot gebruikers kan invloed hebben op de prestaties.

Uw omgeving kan zich het beste zo dicht mogelijk bij gebruikers bevinden. Hoewel Power Apps gebruikmaakt van Azure Content Delivery Network voor inhoud, krijgen gegevensoproepen nog steeds de gegevens van de gegevensbron. Een gegevensbron op een andere geografische locatie kan de prestaties van de app nadelig beïnvloeden.

Een grote geografische afstand heeft op verschillende manieren invloed op de prestaties, zoals latentie, verminderde doorvoer, lagere bandbreedte en pakketverlies.

Acceptatielijst niet geconfigureerd

Zorg ervoor dat de vereiste service-URL's niet zijn geblokkeerd of dat ze zijn toegevoegd aan de toelatingslijst van uw firewall. Ga voor een volledige lijst met alle service-URL's die moeten worden toegestaan voor Power Apps naar Vereiste services.

Gebruik van niet-delegeerbare functies en onjuiste limieten voor gegevensrijen voor niet-delegeerbare query's

Delegeerbare functies delegeren de verwerking van gegevens naar de gegevensbron, waardoor de overhead aan de clientzijde wordt geminimaliseerd. Als delegeren niet mogelijk is, kunt u de limiet voor gegevensrijen voor niet-delegeerbare query's beperken, zodat het aantal rijen dat wordt geretourneerd door een servergebaseerde verbinding optimaal blijft.

Het gebruik van niet-delegeerbare functies en onjuiste limieten voor gegevensrijen voor niet-delegeerbare query's voegt extra overhead toe aan gegevensoverdracht. Deze overhead resulteert in manipulatie van de ontvangen gegevens naar JS heap aan de clientzijde. Gebruik zo mogelijk delegeerbare functies voor de app en gebruik de optimale limiet voor gegevensrijen voor niet-delegeerbare query's.

Meer informatie: Delegatie gebruiken, Delegatie-overzicht

OnStart-gebeurtenis moet worden afgesteld

De gebeurtenis OnStart wordt uitgevoerd wanneer de toepassing wordt geladen. Grote hoeveelheden gegevens oproepen met de functies in de eigenschap OnStart van de app leidt ertoe dat de app langzaam wordt geladen. Een scherm met een sterke afhankelijkheid van besturingselementen en waarden die in een ander scherm zijn gedefinieerd, wordt beïnvloed door langzame schermnavigatie.

In de volgende secties worden enkele van de meest voorkomende problemen beschreven die in deze situaties optreden.

Hoog aantal oproepen in de OnStart-gebeurtenis waardoor de app langzaam start

In een onderneming kan het volume aan gegevensoproepen naar een centrale gegevensbron een server-bottleneck of resourceconflicten veroorzaken.

Gebruik een cachemechanisme om gegevensoproepen te optimaliseren. Een enkele app kan door veel gebruikers worden gebruikt, wat resulteert in veel gegevensoproepen per gebruiker naar de eindpunten van de server. Deze gegevensoproepen kunnen een plek zijn waar de bottleneck of aanvraagbeperking kan optreden.

Latentie bij OnStart-gebeurtenis vanwege zware scripts

Zware scripts bij de gebeurtenis OnStart zijn een van de meest voorkomende fouten bij het ontwerpen van canvas-apps. U moet alleen de benodigde gegevens ophalen die nodig zijn om de app te starten.

Optimaliseer de formule in een OnStart-gebeurtenis. Verplaats bijvoorbeeld enkele functies naar de eigenschap OnVisible. Op deze manier kunt u de app snel laten starten en kunnen andere stappen doorgaan terwijl de app wordt geopend.

Meer informatie: De eigenschap OnStart optimaliseren

Tip

Het wordt aanbevolen om de eigenschap App.StartScreen te gebruiken omdat hiermee het starten van de app wordt vereenvoudigd en de prestaties van de app worden verbeterd.

Geheugendruk aan de clientzijde

Een controle op het geheugengebruik van canvas-apps is belangrijk omdat de app meestal op mobiele apparaten wordt uitgevoerd. Geheugenuitzonderingen in de heap zijn de meest waarschijnlijke oorzaak achter een canvas-app die crasht of vastloopt op bepaalde apparaten.

Een JavaScript (JS)-heap kan het maximum bereiken vanwege zware scripts die aan de clientzijde worden uitgevoerd voor het toevoegen, samenvoegen, filteren, sorteren of groeperen van kolommen. In de meeste gevallen kan een uitzondering wegens onvoldoende geheugen bij de heap in de client ervoor zorgen dat de app vastloopt of crasht.

Bij het gebruik van gegevens uit bronnen zoals Dataverse of SQL Server, kunt u een object View gebruiken om ervoor te zorgen dat samenvoegen, filteren, groeperen of sorteren plaatsvindt aan de serverzijde in plaats van aan de clientzijde. Deze benadering vermindert de overhead van de client voor scripts voor dergelijke acties.

Als clientbelastende bewerkingen, zoals JOIN of Group By aan de clientzijde plaatsvinden met een gegevensset met 2000 of meer records, neemt het aantal objecten in de heap toe, wat resulteert in het overschrijden van geheugenlimieten.

Met ontwikkelaarstools voor de meeste browsers kunt u geheugen profileren. Hiermee worden de heapgrootte, documenten, knooppunten en listeners gevisualiseerd. Profileer de prestaties van de app met behulp van een browser, zoals beschreven in Overzicht van ontwikkelhulpprogramma's voor Microsoft Edge (Chromium). Controleer de scenario's die de geheugendrempel van de JS-heap overschrijden. Meer informatie: Geheugenproblemen oplossen

Een voorbeeld van geheugendruk voor een app gezien vanuit de ontwikkelaarstools van een browser.

Prestatieoverwegingen voor de SQL Server-connector

U kunt gebruikmaken van de SQL Server-connector voor Power Apps om verbinding te maken met SQL Server on-premises of Azure SQL Database. In dit gedeelte worden veelvoorkomende prestatiegerelateerde problemen en oplossingen beschreven voor het gebruik van deze connector voor een canvas-app. Meer informatie: Verbinding maken met SQL Server vanuit Power Apps, Een canvas-app maken vanuit Azure SQL Database

Notitie

Hoewel in deze sectie wordt verwezen naar de SQL Server-connector voor prestatieproblemen en oplossingen, zijn de meeste aanbevelingen ook van toepassing bij het gebruik van elk willekeurig databasetype als de gegevensbron, zoals MySQL of PostgreSQL.

Laten we eens kijken naar de veelvoorkomende prestatieproblemen en oplossingen bij het gebruik van de SQL Server-connector voor canvas-apps.

N+1 query

Galerieën die te veel verzoeken aan servers genereren, veroorzaakten N+1-queryproblemen. Het N+1-queryprobleem is een van de meest voorkomende problemen bij het gebruik van het besturingselement Galerie.

Gebruik om het probleem te voorkomen view-objecten in de SQL-backend of wijzig de gebruikersinterfacescenario's.

Tabelscan in plaats van indexzoekopdracht

Een app kan langzamer worden als de functies die door de app worden gebruikt, query's uitvoeren in de database die resulteren in tabelscans in plaats van indexzoekopdrachten. Meer informatie: Hints, tabelSCAN en indexOPZOEKOPDRACHT

Gebruik om dergelijke problemen op te lossen StartsWith in plaats van IN in de formule. Bij gebruik van een SQL-gegevensbron resulteert de operator StartsWith in een indexzoekopdracht, maar de IN-operator resulteert in een index- of tabelscan.

Langzame query's

U kunt trage query's en indexen voor de SQL-database profileren en afstemmen. Als er bijvoorbeeld een formule is die bepaalde gegevens met aflopende (DESC) volgorde voor een bepaalde kolom ophaalt, moet die sorteerkolom een index met aflopende volgorde hebben. De indexsleutel maakt standaard oplopende (ASC) volgorde.

U kunt ook het URL-adres van gegevensverzoeken controleren. Het volgende gegevensverzoekfragment (gedeeltelijke OData-aanroep) vraagt bijvoorbeeld aan SQL om 500 records te retourneren waarvan de kolom overeenkomt met Waarde en volgorde per ID in aflopende volgorde.

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

Dit helpt de indexvereisten te begrijpen om dergelijke verzoekvoorwaarden te dekken. In dit voorbeeld moet de ID-kolom een index met aflopende volgorde hebben om de query sneller uit te voeren.

Controleer het uitvoeringsplan van langzame query's om te zien of er een tabel- of indexscan bestaat. Bewaak eventuele buitensporige kosten van Key Lookup in het uitvoeringsplan.

Meer informatie:

Databaseresourceconflicten

Zorg ervoor dat de gegevensbron, SQL-database, geen resourceconflicten heeft, zoals processor-bottlenecks, I/O-conflicten, geheugendruk of tempDB-conflicten. Controleer ook op vergrendelingen, wachtrijen, deadlocks en time-outs voor query's.

Tip

Gebruik automatische afstemming voor inzichten in mogelijke prestatieproblemen bij query's, aanbevolen oplossingen en om de geïdentificeerde problemen automatisch op te lossen.

Thick client- of buitensporige verzoeken

Een app waarop de bewerkingen Group By, Filter By of JOIN aan de clientzijde worden uitgevoerd, gebruikt processor- en geheugenbronnen van de clientapparaten. Afhankelijk van de gegevensgrootte kunnen deze bewerkingen meer scripttijd vergen aan de clientzijde, waardoor de grootte van de JS-heap op de cliënt toeneemt. Bij gebruik van on-premises gegevensbron neemt dit probleem toe aangezien elke opzoekgegevensoproep via de gegevensgateway naar de gegevensbron gaat.

Gebruik in dergelijke situaties het View-object in SQL-database voor de bewerking Group By, Filter By of JOIN. Weergaven kunnen selectieve kolommen gebruiken en onnodige kolommen verwijderen met big data-typen zoals NVARCHAR(MAX), VARCHAR(MAX) en VARBINARY(MAX).

Tip

Deze aanpak helpt ook bij het aanpakken van het N+1 queryprobleem.

Gegevensgrootte overgedragen aan de client

Standaard toont een canvas-app gegevens met behulp van de tabellen, of weergaven, van de beschikbare database-objecten. Het ophalen van alle kolommen uit een tabel kan resulteren in een trage respons, vooral bij gebruik van big data-typen zoals NVARCHAR (MAX).

Het overbrengen van grote hoeveelheden gegevens naar clients kost tijd. Deze overdracht resulteert ook in meer scripttijd bij grote hoeveelheden gegevens in de JS-heap aan de clientzijde, zoals eerder beschreven in dit artikel.

Om de omvang van de gegevens die naar de client worden overgedragen te verkleinen, gebruikt u weergaven met de specifieke kolommen die nodig zijn voor de app en zorgt u ervoor dat expliciete kolomselectie is ingeschakeld, zoals eerder in dit artikel beschreven.

Overwegingen die specifiek zijn voor SQL Server on-premises

De prestaties van een canvas-app met de SQL Server-connector met een on-premises gegevensgateway kunnen op verschillende manieren worden beïnvloed. Deze sectie bevat de algemene prestatieproblemen en oplossingen die specifiek zijn voor het gebruik van een on-premises databasebron.

Beschadigde on-premises gegevensgateway

Organisaties kunnen meerdere knooppunten definiëren voor on-premises-gegevensgateways. Zelfs als een van de knooppunten onbereikbaar is, zullen gegevensverzoeken naar het beschadigde knooppunt het resultaat niet binnen een redelijk tijdsbestek retourneren of er ontstaan na een tijdje wachten foutmeldingen over onbereikbare knooppunten.

Zorg ervoor dat alle on-premises gegevensgateway-knooppunten in orde zijn en geconfigureerd zijn met een minimale netwerklatentie tussen de knooppunten en de SQL-instantie.

Locatie van de on-premises gegevensgateway

Een gegevensgateway vereist netwerkoproepen naar on-premises gegevensbronnen om de OData-verzoeken te interpreteren. De gegevensgateway moet bijvoorbeeld het gegevenstabelschema begrijpen om OData-aanvragen te kunnen vertalen in SQL-instructies voor gegevensbewerkingstaal (DML). Extra overhead wordt toegevoegd wanneer de gegevensgateway wordt geconfigureerd op een aparte locatie met een hoge netwerklatentie tussen de gegevensgateway en het SQL-exemplaar.

In een bedrijfsomgeving wordt het hebben van een schaalbare gegevensgatewaycluster aanbevolen wanneer zware gegevensverzoeken worden verwacht. Controleer hoeveel verbindingen er tot stand worden gebracht tussen de gegevensgateway-knooppunten en de SQL-instantie.

Door de gelijktijdige verbindingen in een on-premises gegevensgateway of in een SQL-exemplaar te controleren, kan uw organisatie identificeren op welk punt de gegevensgateway moet worden uitgeschaald en met hoeveel knooppunten.

Schaalbaarheid van gegevensgateway

Als u verwacht toegang te krijgen tot een grote hoeveelheid gegevens van de on-premises gegevensgateway, kan slechts een enkel knooppunt van de on-premises gegevensgateway een bottleneck worden om een dergelijk groot aantal verzoeken te kunnen verwerken.

Een enkel knooppunt van de on-premises gegevensgateway kan voldoende zijn om 200 of minder gelijktijdige verbindingen te verwerken. Als al deze gelijktijdige verbindingen actief query's uitvoeren, moeten andere verzoeken echter wachten op een beschikbare verbinding.

Voor informatie over hoe u ervoor kunt zorgen dat uw on-premises-datagateway schaalt in overeenstemming met de hoeveelheid gegevens en verzoeken, gaat u naar Prestaties van on-premises gegevensgateway controleren en optimaliseren.

Overwegingen die specifiek zijn voor Azure SQL Database

Canvas-apps kunnen verbinding maken met Azure SQL Database met behulp van de SQL Server-connector. Een veelvoorkomende oorzaak van prestatieproblemen bij het gebruik van Azure SQL Database is het selecteren van de verkeerde laag voor uw zakelijke vereisten.

Azure SQL Database is beschikbaar in verschillende servicelagen, met verschillende mogelijkheden om aan verschillende zakelijke vereisten te voldoen. Ga voor meer informatie over lagen naar Azure SQL Database-documentatie.

Bij zware gegevensverzoeken kunnen de bronnen op de door u geselecteerde laag worden beperkt zodra de drempelwaarde wordt bereikt. Een dergelijke beperking brengt de prestaties van de volgende reeks query's in gevaar.

Controleer de servicelaag van Azure SQL Database. Voor lagere lagen gelden enkele beperkingen. Vanuit het oogpunt van prestaties zijn CPU, I/O-doorvoer en latentie belangrijk. Controleer daarom regelmatig de prestaties van de SQL-database en controleer of het resourcegebruik de drempel overschrijdt. Bijvoorbeeld: on-premises SQL Server stelt normaal gesproken de drempel van het CPU-gebruik in op ongeveer 75%..

Prestatieoverwegingen voor de SharePoint-connector

U kunt de SharePoint-connector gebruiken om apps te maken met behulp van gegevens uit Microsoft Lijsten. U kunt ook canvas-apps rechtstreeks vanuit de lijstweergave maken. Laten we eens kijken naar de veelvoorkomende prestatieproblemen en oplossingen bij het gebruik van een SharePoint-gegevensbron met canvas-apps.

Te veel dynamische opzoekkolommen

SharePoint ondersteunt verschillende gegevenstypen, inclusief dynamische zoekopdrachten, zoals Persoon, Groep en Berekend. Als een lijst te veel dynamische kolommen definieert, kost het meer tijd om deze dynamische kolommen binnen SharePoint te manipuleren voordat gegevens worden geretourneerd naar de client waarop de canvas-app wordt uitgevoerd.

Maak niet overdadig gebruik van de dynamische opzoekkolommen in SharePoint. Dit overmatige gebruik kan resulteren in vermijdbare en extra overhead aan de SharePoint-kant voor manipulatie van gegevens. U kunt bijvoorbeeld ook statische kolommen gebruiken om e-mailaliassen of namen van personen te behouden.

Afbeeldingskolom en -bijlage

De grootte van een afbeelding en het bijgevoegde bestand kunnen bijdragen aan een trage reactie tijdens het ophalen naar de client.

Beoordeel uw lijst en zorg ervoor dat alleen de noodzakelijke kolommen zijn gedefinieerd. Het aantal kolommen in de lijst is van invloed op de prestaties van de gegevensverzoeken. Dit komt doordat de overeenkomende records, of de records tot aan de gedefinieerde limieten voor de gegevensrij, worden opgehaald en teruggestuurd naar de client met alle kolommen die zijn gedefinieerd in de lijst, of de app ze nu allemaal gebruikt of niet.

Schakel de functie voor expliciete kolomselectie, zoals eerder beschreven in dit artikel in om alleen de kolommen te doorzoeken die door de app worden gebruikt.

Grote lijsten

Als u een grote lijst met honderdduizenden records heeft, kunt u overwegen om de lijst te partitioneren of op te splitsen in verschillende lijsten op basis van parameters zoals categorieën of datum en tijd.

Uw gegevens kunnen bijvoorbeeld in verschillende lijsten op jaar- of maandbasis worden opgeslagen. In dat geval kunt u de app ontwerpen om een gebruiker een tijdvenster te laten selecteren en de gegevens binnen dat bereik op te halen.

Binnen een gecontroleerde omgeving heeft de prestatiebenchmark aangetoond dat de prestaties van OData-aanvragen op basis van Microsoft Lijsten of SharePoint sterk is gerelateerd aan het aantal kolommen in de lijst en het aantal rijen dat wordt opgehaald (beperkt door de limiet voor gegevensrijen voor niet-delegeerbare query's). Bij minder kolommen en een lagere limiet voor gegevensrijen kan een canvas-app beter presteren.

In de echte wereld zijn apps echter ontworpen om aan bepaalde zakelijke vereisten te voldoen. Het is misschien niet snel of eenvoudig om de limiet voor gegevensrijen of het aantal kolommen in een lijst te beperken. U wordt echter aangeraden om de OData-verzoeken aan de clientzijde te controleren en de limiet voor gegevensrijen af te stemmen voor niet-delegeerbare query's en het aantal kolommen in de lijst.

Prestatieoverwegingen voor het gebruik van Dataverse als de gegevensbron

Wanneer u Microsoft Dataverse als de gegevensbron gebruikt, gaan gegevensverzoeken rechtstreeks naar het omgevingsexemplaar, zonder via Azure API Management te gaan. Meer informatie: Gegevensoproepstroom bij verbinding met Microsoft Dataverse

Tip

Wanneer aangepaste tabellen worden gebruikt in Dataverse, is mogelijk extra beveiligingsconfiguratie vereist zodat gebruikers de records kunnen bekijken met canvas-apps. Meer informatie: Beveiligingsconcepten in Dataverse, Gebruikersbeveiliging configureren voor resources in een omgeving en Beveiligingsrollen en bevoegdheden

Een canvas-app verbonden met Dataverse werkt mogelijk traag als deze clientintensieve scripts uitvoert, zoals Filter By of JOIN aan de clientzijde in plaats van aan de serverzijde.

Gebruik Dataverse-weergaven wanneer mogelijk. Een weergave met de vereiste join- of filtercriteria helpt de overhead van het gebruik van een hele tabel te verminderen. Als u bijvoorbeeld tabellen moet samenvoegen en hun gegevens moet filteren, kunt u een weergave definiëren door ze samen te voegen en alleen de kolommen te definiëren die u nodig hebt. Gebruik vervolgens deze weergave in uw app om deze overhead in plaats van aan de clientzijde te maken aan de serverzijde voor het samenvoegen/filteren. Deze methode vermindert niet alleen de extra bewerkingen, maar ook de gegevensoverdracht. Ga voor informatie over het bewerken van filter- en sorteercriteria naar Bewerk filtercriteria.

Prestatieoverwegingen voor de Excel-connector

De Excel-connector biedt connectiviteit van een canvas-app naar de gegevens in een tabel in een Excel-bestand. Deze connector heeft beperkingen in vergelijking met andere gegevensbronnen, bijvoorbeeld beperkte delegeerbare functies, waarmee de canvas-app wordt beperkt om tot slechts 2000 gegevensrecords uit de tabel te laden. Als u meer dan 2000 records wilt laden, verdeelt u uw gegevens in verschillende gegevenstabellen als andere gegevensbronnen.

Laten we eens kijken naar de veelvoorkomende prestatieproblemen bij het gebruik van Excel als de gegevensbron voor canvas-apps en hoe u deze problemen oplost.

Te veel gegevenstabellen en grote gegevensomvang

Een app kan traag worden wanneer een Excel-bestand met te veel gegevenstabellen wordt gebruikt of met gegevenstabellen met een enorme hoeveelheid gegevens in verschillende kolommen. Een Excel-bestand is geen relationele database of een gegevensbron die delegeerbare functies biedt. Power Apps moet eerst gegevens uit de gedefinieerde gegevenstabellen laden en gebruikt vervolgens functies zoals Filteren, Sorteren, Samenvoegen, Groeperen op en Zoeken.

Wanneer u te veel gegevenstabellen hebt, met een groot aantal rijen en kolommen, heeft dit invloed op de app-prestaties en de overhead van de client, omdat elke gegevenstabel moet worden gemanipuleerd binnen de JS-heap. Dit effect leidt er ook toe dat de app meer geheugen op de client verbruikt.

Om ervoor te zorgen dat uw app niet wordt beïnvloed door dit probleem, definieert u alleen de benodigde kolommen in de gegevenstabel in een Excel-bestand.

Zware transacties

Excel is geen systeem voor relationele databases. Eventuele wijzigingen van een app worden door Excel op dezelfde manier beheerd als wanneer een gebruiker gegevens in een Excel-bestand wijzigt. Als de app een groot aantal leesbewerkingen heeft, maar minder CRUD-bewerkingen, werkt deze mogelijk goed. Als de app echter zware transacties uitvoert, kan dit de prestaties van de app nadelig beïnvloeden.

Er is geen specifieke drempelwaarde voor het aantal transacties, aangezien deze ook afhankelijk zijn van de gegevens die worden gemanipuleerd. Verschillende andere aspecten hebben ook invloed op de prestaties van de app, zoals de netwerkoverhead of het apparaat van de gebruiker.

Als u alleen-lezen gegevens heeft, kunt u dergelijke gegevens lokaal in de app importeren in plaats van ze te laden vanuit de gegevensbron. Gebruik voor zakelijke apps liever gegevensbronnen zoals Dataverse, SQL Server of SharePoint.

Bestandsgrootte

U kunt kiezen uit een breed assortiment opties voor cloudopslag met variërende of configureerbare opslagcapaciteit voor het Excel-bestand. Een enkel groot Excel-bestand met alle tabellen gedefinieerd in één bestand voegt echter extra overhead toe voor de app tijdens het downloaden van het bestand en het lezen van de gegevens die aan de clientzijde moeten worden geladen.

In plaats van één groot bestand te gebruiken, splitst u de gegevens op in meerdere Excel-bestanden met een minimum aan gegevenstabellen. Maak vervolgens alleen verbinding met een bestand als u het nodig hebt. Op deze manier gebeurt het laden van de gegevens uit de gegevenstabel in fragmenten, waardoor de overhead van een groot aantal tabellen of grote gegevenssets wordt verminderd.

Bestandslocatie

De geografische locatie van de gegevensbron, en de nabijheid van clientlocaties kan resulteren in een veelvoorkomend knelpunt in de prestaties van de app en netwerklatentie veroorzaken. Dit effect kan worden wanneer een mobiele client beperkte bandbreedte voor connectiviteit heeft.

Het is beter om het bestand in de buurt van uw eindgebruikers (of de meeste eindgebruikers, in het geval van een wereldwijde doelgroep) te houden, zodat het bestand snel kan worden gedownload.

Volgende stappen

Tips en best practices om de prestaties van canvas-apps te verbeteren

Zie ook

De uitvoeringsfasen en de stroom van gegevensaanroepen van canvas-apps begrijpen
Veelvoorkomende bronnen van trage prestaties voor een canvas-app
Algemene problemen en oplossingen voor Power Apps
Opstartproblemen oplossen voor Power Apps