Inzicht krijgen in de uitvoeringsfasen van canvas-apps, de gegevensaanroepstroom en prestatiebewaking

Wanneer een gebruiker een canvas-app opent, doorloopt de app verschillende uitvoeringsfasen voordat de gebruikersinterface wordt weergegeven. Terwijl de app wordt geladen, maakt deze verbinding met verschillende gegevensbronnen—zoals SharePoint, Microsoft Dataverse, SQL Server (on-premises), Azure SQL Database (online), Excel en Oracle.

In dit artikel leert u over deze verschillende uitvoeringsfasen, hoe een app verbinding maakt met gegevensbronnen en over tools die u kunt gebruiken om de prestaties te bewaken.

Uitvoeringsfasen in canvas-apps

Een canvas-app doorloopt de volgende uitvoeringsfasen voordat de interface aan een gebruiker wordt getoond:

1. De gebruiker verifiëren: de nieuwe gebruiker wordt gevraagd om in te loggen met inloggegevens voor de verbindingen die de app nodig heeft. Als diezelfde gebruiker de app opnieuw opent, wordt die persoon mogelijk opnieuw gevraagd om aan te melden, afhankelijk van het beveiligingsbeleid van de organisatie.

2. Metagegevens ophalen: haalt metagegevens op, zoals de versie van het Power Apps-platform waarop de app wordt uitgevoerd en de bronnen waaruit gegevens moeten worden opgehaald.

3. De app initialiseren: alle taken die zijn opgegeven in de eigenschap OnStart worden uitgevoerd.

4. De schermen weergeven: het eerste scherm wordt weergegeven met besturingselementen die de app vult met gegevens. Als de gebruiker andere schermen opent, worden deze door de app weergegeven met behulp van hetzelfde proces.

Gegevensoproepstroom in canvas-apps

Gegevensaanroepen van canvas-apps verzenden gegevens naar gegevensbronnen in tabelvorm met connectoren via het OData-protocol. OData-verzoeken stromen naar back-endlagen om contact op te nemen met de doel-gegevensbron, en halen gegevens voor de client op of voeren gegevens door naar de gegevensbron. Op actie gebaseerde connectoren die API's mogelijk maken, werken op dezelfde manier.

Als u begrijpt hoe OData- en API-verzoeken door canvas-apps gaan, kunt u de prestaties van uw canvas-app en uw back-endgegevensbronnen optimaliseren.

In dit gedeelte leert u hoe de gegevensoproep stroomt in canvas-apps met verschillende gegevensbrontypen.

Gegevensoproepstroom met online gegevensbronnen

Het volgende diagram laat zien hoe een typisch gegevensverzoek in een canvas-app (linkerkant) door serverlagen gaat, de doelgegevensbron (rechterkant) bereikt en de gegevens retourneert aan de client.

Elke laag in het vorige diagram kan snel presteren of wat overhead hebben tijdens het verwerken van het verzoek. In veel apps kunnen twee specifieke plekken vaak merkbare overhead opleveren:

• Back-endgegevensbron tijdens het verwerken van het verzoek.

• Client tijdens het verzenden van het verzoek of tijdens het manipuleren van de ontvangen gegevens in het heapgeheugen en het uitvoeren van de bijbehorende JavaScript-functies om gegevens te verwerken die in schermen moeten worden weergegeven.

Gegevensoproepstroom met on-premises gegevensgateway

Als een canvas-app verbinding maakt met een on-premises gegevensbron zoals SQL-server, hebt u een andere laag genaamd on-premises gegevensgateway nodig. Deze gateway is verplicht voor toegang tot on-premises gegevensbronnen. Deze zorgt voor het converteren van OData-protocolverzoeken naar SQL DML-instructies (Data Manipulation Language).

Het volgende diagram laat zien waar en hoe de on-premises gegevensgateway wordt gebruikt om gegevensverzoeken te verwerken.

Als de app een gegevensbron on-premises gebruikt, hebben de locatie en de specificatie van de gegevensgateway ook invloed op de prestaties van gegevensoproepen.

Gegevensoproepstroom met Microsoft Dataverse

Wanneer u Microsoft Dataverse als de gegevensbron gebruikt, gaan gegevensverzoeken rechtstreeks naar het omgevingsexemplaar, zonder via Azure API Management te gaan. Hierdoor zijn de prestaties van gegevensoproepen beter in vergelijking met de rest van de gegevensbronnen. De app is standaard verbonden met Microsoft Dataverse wanneer u een nieuwe canvas-app maakt.

Als u begrijpt hoe gegevensoproepen zich verplaatsen, kunt u dieper ingaan op de details van de prestatiebeoordeling van uw app. Kortom, prestatieoverhead kan optreden bij elk van de lagen, van de client, APIM (API Management), connector, on-premises gegevensgateway of de back-endgegevensbronnen.

Prestaties meten

Power Apps-controlehulpprogramma

Hoewel u de ontwikkelhulpprogramma's van de browser kunt gebruiken om de prestaties te bekijken, verdeelt Power Apps de reeks oproepen in het Monitoring-hulpprogramma in alleen de oproepen van Power Apps.

Met het Power Apps-controlehulpprogramma kunt u bijhouden wat er daadwerkelijk naar de gegevensbron wordt verzonden en tijdstempels voor wanneer verzoeken worden verzonden en antwoorden van de server komen.

In dit artikel vindt u meer informatie over het controlehulpprogramma: Fouten in canvas-apps opsporen met Monitor .

Geheugendruk meten aan de clientzijde

Om het geheugenverbruik grafisch te zien, kunt u de ontwikkelhulpprogramma's van uw browser gebruiken om het geheugen te 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

Volgende stappen

Kleine nettolading van gegevens

Zie ook

Problemen met Power Apps oplossen

Notitie

Laat ons uw taalvoorkeuren voor documentatie weten! Beantwoord een korte enquête. (houd er rekening mee dat deze in het Engels is)

De enquête duurt ongeveer zeven minuten. Er worden geen persoonlijke gegevens verzameld (privacyverklaring).