Problemi di prestazioni comuni delle app canvas e soluzioni

Puoi creare app canvas usando una diversa matrice di origini dati. Scegli l'origine dati e il connettore a seconda delle esigenze aziendali e degli scenari per cui l'app è progettata. Per le app aziendali, Microsoft Dataverse è l'origine dati consigliata poiché fornisce diversi vantaggi in termini di prestazioni. Per le app con poche transazioni, puoi utilizzare qualsiasi altra origine dati disponibile nel tuo ambiente.

Per considerazioni sulle prestazioni di un'app, pensa al numero di utenti che utilizzeranno l'app una volta pubblicata; il volume delle transazioni di creazione, recupero, aggiornamento ed eliminazione (CRUD); il tipo di interazioni con i dati; l'accesso geografico e i tipi di dispositivi che gli utenti hanno.

In questo articolo verranno illustrati alcuni dei problemi di prestazioni più comuni che possono rallentare l'esecuzione delle app canvas e come risolverli. Queste informazioni ti aiuteranno a migliorare le prestazioni dell'app tenendo conto del tuo piano aziendale e della tua crescita.

Inizieremo con alcuni dei problemi di prestazioni comuni che si verificano indipendentemente dal connettore utilizzato. Nelle sezioni successive verranno illustrati i problemi di prestazioni e le risoluzioni specifiche per i vari connettori.

Prima di iniziare, assicurati di conoscere le fasi di esecuzione delle app canvas e il flusso di chiamate dati. Inoltre, leggi le fonti comuni di rallentamento delle prestazioni per un'app canvas per informazioni sulle insidie comuni che puoi evitare durante la progettazione o l'aggiornamento delle app canvas.

Set di dati di grandi dimensioni che si caricano lentamente su piattaforme diverse

Le prestazioni di un'app possono variare durante il caricamento di grandi set di dati su piattaforme diverse come iOS o Android. Questa variazione si verifica a causa delle diverse limitazioni delle richieste di rete su ciascuna piattaforma. Ad esempio, il numero di richieste di rete simultanee consentite può variare a seconda della piattaforma. Questa differenza può avere un impatto importante sul tempo di caricamento dei dati per set di dati di grandi dimensioni.

Ti consigliamo di caricare solo i dati che devi visualizzare immediatamente sullo schermo. Per altri dati, impagina e memorizza nella cache i tuoi dati. Maggiori informazioni: Suggerimenti e procedure consigliate per migliorare le prestazioni delle app canvas

Troppe colonne recuperate

Ti consigliamo di selezionare solo le colonne necessarie per l'app. L'aggiunta di altre o tutte le colonne dall'origine dati scarica tutti i dati nelle colonne. Questa azione si traduce in un numero elevato di chiamate di che sovraccaricano la rete e quindi in un elevato utilizzo della memoria nel dispositivo client. Questo problema può avere un impatto ancora maggiore sugli utenti con dispositivi mobili se la larghezza di banda della rete è limitata, se un dispositivo ha una memoria limitata o un processore legacy.

Ad esempio, se utilizzi Dataverse come origine dati per la tua app, assicurati di aver abilitato la funzionalità Selezione colonna esplicita. Questa funzionalità consente a Power Apps di limitare il recupero dei dati solo per le colonne utilizzate nell'app.

Per attivare la funzione di selezione esplicita delle colonne nell'app Canvas, vai a Impostazioni > Funzionalità in arrivo > Anteprima, quindi abilita l'opzione Selezione colonna esplicita.

Browser legacy o non supportati

Gli utenti che utilizzano browser non supportati o legacy potrebbero riscontrare problemi di prestazioni. Assicurati che gli utenti utilizzino solo browser supportati per l'esecuzione di app canvas.

Prestazioni lente a causa della distanza geografica

La posizione geografica dell'ambiente e la distanza dell'origine dati dagli utenti possono influire sulle prestazioni.

Ti consigliamo di posizionare l'ambiente vicino agli utenti. Anche se Power Apps utilizza Azure Content Delivery Network per i contenuti, le chiamate dati ricevono comunque i dati dall'origine dati. Un'origine dati che si trova in un'altra posizione geografica può influire negativamente sulle prestazioni dell'app.

Una distanza di posizione geografica eccessiva influisce sulle prestazioni in diversi modi, come latenza, velocità effettiva ridotta, larghezza di banda inferiore o perdita di pacchetti.

Elenco elementi consentiti non configurato

Assicurati che gli URL del servizio richiesto non siano stati bloccati o che siano stati aggiunti all'elenco elementi consentiti del firewall. Per un elenco completo di tutti gli URL di servizio che devono essere consentiti per Power Apps, vai a Servizi obbligatori.

Utilizzo di funzioni non delegabili e limite di righe di dati inappropriato per query non delegabili

Le funzioni delegabili delegano l'elaborazione dei dati all'origine dati, riducendo al minimo il sovraccarico dal lato client. Quando la delega non è possibile, puoi limitare il limite di righe di dati per le query non delegabili in modo che il numero di righe restituite da una connessione basata su server rimanga ottimale.

L'uso di funzioni non delegabili e un limite di righe di dati per query non delegabili inappropriato aggiunge sovraccarico sul trasferimento dei dati. Questo sovraccarico si traduce nella manipolazione dei dati ricevuti su JS heap dal lato client. Assicurati di usare le funzioni delegabili per l'app ogni volta che sono disponibili e il limite di righe di dati ottimale per le query non delegabili.

Altre informazioni: Utilizzare la delega, Panoramica della delega.

L'evento OnStart deve essere ottimizzato

L'evento OnStart viene eseguito durante il caricamento dell'applicazione. La chiamata di grandi quantità di dati utilizzando le funzioni nella proprietà OnStart dell'app causa un rallentamento nel caricamento dell'app. Una schermata con una forte dipendenza dei controlli e dei valori definiti su un'altra schermata sarà influenzata dalla navigazione lenta sullo schermo.

Le sezioni seguenti descrivono alcuni dei problemi più comuni riscontrati in queste situazioni.

Numero elevato di chiamate nell'evento OnStart che causano l'avvio lento dell'app

In un'azienda, il volume delle chiamate di dati a un'origine dati centrale può causare colli di bottiglia del server o conflitti di risorse.

Utilizza un meccanismo di cache per ottimizzare le chiamate dati. Una singola app può essere utilizzata da molti utenti, generando più chiamate di dati per utente che raggiungono gli endpoint del server. Queste chiamate di dati potrebbero essere all'origine di un collo di bottiglia o di una limitazione.

Latenza sull'evento OnStart a causa di script pesanti

Gli script pesanti sull'evento OnStart sono uno degli errori più comuni durante la progettazione di app canvas. Devi ricevere solo i dati necessari per l'avvio dell'app.

Ottimizza la formula in un evento OnStart. Ad esempio, puoi spostare alcune funzioni invece nella proprietà OnVisible. In questo modo, puoi avviare l'app velocemente e gli altri passaggi possono continuare mentre l'app viene aperta.

Maggiori informazioni: Ottimizzare la proprietà OnStart

Suggerimento

Ti consigliamo di utilizzare la proprietà App.StartScreen poiché semplifica l'avvio dell'app e ne migliora le prestazioni.

Pressione di memoria sul lato client

È importante controllare il consumo di memoria di un'app canvas poiché la maggior parte delle volte l'app viene eseguita su dispositivi mobili. Le eccezioni di memoria nell'heap sono la causa più probabile dell'arresto anomalo o del blocco di un'app canvas su determinati dispositivi.

Un heap JavaScript (JS) può raggiungere il limite a causa di pesanti script in esecuzione sul lato client per l'aggiunta, l'unione, il filtro, l'ordinamento o il raggruppamento di colonne. Nella maggior parte dei casi, un'eccezione di memoria insufficiente nell'heap del client può causare l'arresto anomalo o il blocco dell'app.

Quando si utilizzano dati provenienti da origini quali Dataverse o SQL Server, puoi utilizzare un oggetto Visualizza per fare in modo che l'unione, l'applicazione di filtri, il raggruppamento o l'ordinamento avvengano sul lato server anziché sul lato client. Questo approccio riduce il sovraccarico del client dovuto alla creazione di script per tali azioni.

Se operazioni client pesanti come JOIN o Raggruppa per sono avvenute sul lato client con un set di dati con 2000 record o più, gli oggetti nell'heap aumenteranno con il risultato di superare il limite di memoria.

Gli strumenti di sviluppo per la maggior parte dei browser consentono di creare profili di memoria. Consentono di visualizzare dimensione dell'heap, documenti, nodi e listener. Crea il profilo delle prestazioni dell'app utilizzando un browser, come descritto in Microsoft Edge (Chromium) - Panoramica degli strumenti per sviluppatori. Verifica gli scenari che superano la soglia di memoria dell'heap JS. Maggiori informazioni: Risolvere i problemi di memoria

Considerazioni sulle prestazioni per il connettore SQL Server

Puoi utilizzare il connettore SQL Server per Power Apps per connetterti a SQL Server locale o al database SQL di Azure. Questa sezione descrive i problemi e le soluzioni comuni relativi alle prestazioni per l'utilizzo di questo connettore per un'app canvas. Maggiori informazioni: Connessione a SQL Server da Power Apps, Creare un'app canvas dal database SQL di Azure

Nota

Sebbene questa sezione faccia riferimento al connettore SQL Server per problemi di prestazioni e risoluzioni, la maggior parte dei consigli si applica anche quando si utilizza qualsiasi tipo di database come origine dati, ad esempio MySQL o PostgreSQL.

Diamo un'occhiata ai problemi di prestazioni e alle risoluzioni comuni quando si usa il connettore SQL Server per le app canvas.

Query N+1

Le raccolte che generano troppe richieste ai server causano un problema di query N+1. Il problema di query N+1 è uno dei problemi più comunemente riscontrati quando si utilizza il controllo Raccolta.

Per evitare il problema, usa visualizza oggetti nel back-end SQL o modifica gli scenari dell'interfaccia utente.

Scansione della tabella invece della ricerca nell'indice

Un'app può rallentare se le funzioni utilizzate dall'app eseguono query nel database con conseguente scansioni di tabelle anziché ricerche di indice. Maggiori informazioni: Suggerimenti, Table SCAN e Index SEEK

Per risolvere tali problemi, utilizza StartsWith invece di IN nella formula. Quando si utilizza un'origine dati SQL, l'operatore StartsWith risulta in una ricerca di indice; ma l'operatore IN genera una scansione dell'indice o della tabella.

Query lente

Crea un profilo e ottimizza le query e gli indici lenti sul database SQL. Ad esempio, se una formula ottiene i dati in ordine decrescente (DESC) su una determinata colonna, quella colonna di ordinamento deve avere un indice in ordine decrescente. La chiave dell'indice crea un ordine crescente (ASC) per impostazione predefinita.

Puoi inoltre controllare l'indirizzo URL delle richieste di dati. Ad esempio, il seguente frammento di richiesta di dati (chiamata OData parziale) chiede a SQL di restituire 500 record corrispondenti alla colonna Valore e disporli per ID in ordine decrescente.

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

Ciò aiuta a comprendere i requisiti dell'indice per coprire condizioni di richiesta simili. In questo esempio, se la colonna ID ha un indice con ordine decrescente, la query viene eseguita più velocemente.

Controlla il piano di esecuzione delle query lente per vedere se esiste una scansione di tabelle o indici. Monitora eventuali costi eccessivi di ricerca della chiave nel piano di esecuzione.

Ulteriori informazioni:

• Monitoraggio e ottimizzazione delle prestazioni
• Monitoraggio delle prestazioni con Query Store
• Panoramica degli eventi estesi

Contesa di risorse del database

Assicurati che il database SQL dell'origine dati non abbia conflitti di risorse come colli di bottiglia del processore, contese di I/O, pressione di memoria o contesa di tipo tempDB. Controlla anche blocchi, attese, deadlock e timeout delle query.

Suggerimento

Utilizza l'ottimizzazione per informazioni dettagliate su potenziali problemi di prestazioni delle query, le soluzioni consigliate e per risolvere automaticamente i problemi identificati.

Thick client o richieste eccessive

Un'app che esegue le operazioni Raggruppa per, Filtra per o JOIN sul lato client usa il processore e le risorse di memoria dai dispositivi client. A seconda della dimensione dei dati, queste operazioni possono richiedere più tempo per lo scripting sul lato client, aumentando la dimensione dell'heap JS sul client. Quando si utilizza un'origine dati locale questo problema aumenta per l'ordine dati locale poiché ogni chiamata di dati di ricerca viaggia verso l'origine dati attraverso il gateway dati.

In tali situazioni, utilizza l'oggetto Visualizza nel database SQL per le operazioni Raggruppa per, Filtra per o JOIN. Le visualizzazioni possono utilizzare colonne selettive e rimuovere le colonne superflue con tipi di big data come NVARCHAR(MAX), VARCHAR(MAX) e VARBINARY(MAX).

Suggerimento

Questo approccio aiuta anche a risolvere il problema delle query N+1.

Dimensione dei dati trasferita al client

Per impostazione predefinita, un'app canvas mostra i dati usando le tabelle o le visualizzazioni dagli oggetti di database disponibili. Il recupero di tutte le colonne da una tabella può causare una risposta lenta, soprattutto quando si utilizzano tipi di big data come NVARCHAR(MAX).

Il trasferimento di grandi quantità di dati ai client richiede tempo. Questo trasferimento comporta anche più tempo di scripting quando ci sono grandi quantità di dati nell'heap JS sul lato client, come descritto in precedenza in questo articolo.

Per ridurre le dimensioni dei dati trasferiti al client, utilizza le visualizzazioni con le colonne specifiche richieste per l'app e assicurati che la selezione esplicita delle colonne sia abilitata, come descritto in precedenza in questo articolo.

Considerazioni specifiche su SQL Server locale

Le prestazioni di un'app canvas che utilizza il connettore SQL Server con un gateway dati locale possono essere influenzate in vari modi. Questa sezione elenca i problemi di prestazioni comuni e le risoluzioni specifiche per l'utilizzo di un'origine database locale.

Gateway dati locale non integro

Le organizzazioni possono definire più nodi per i gateway dati locale. Se anche uno dei nodi è irraggiungibile, le richieste di dati sul nodo non integro non restituiranno il risultato entro un intervallo di tempo accettabile o possono causare messaggi di errore di tipo "non raggiungibile" dopo aver atteso un po' di tempo.

Assicurati che tutti i nodi del gateway dati locale siano integri e configurati con una latenza di rete minima tra i nodi e l'istanza SQL.

Posizione del gateway dati locale

Un gateway dati richiede chiamate di rete alle origini dati locali per interpretare le richieste OData. Ad esempio, il gateway dati deve comprendere lo schema della tabella dati per tradurre le richieste OData in istruzioni SQL Data Manipulation Language (DML). Viene aggiunto un sovraccarico aggiuntivo quando il gateway dati è configurato in una posizione separata con un'elevata latenza di rete tra il gateway dati e l'istanza SQL.

In un ambiente aziendale, è consigliabile disporre di un cluster di gateway dati scalabile quando sono previste richieste di dati pesanti. Verifica quante connessioni vengono stabilite tra i nodi del gateway dati e l'istanza SQL.

Controllando le connessioni simultanee in un gateway dati locale o in un server SQL, la tua organizzazione può individuare il momento in cui il gateway dati deve essere ridimensionato e con quanti nodi.

Scalabilità del gateway dati

Se prevedi di accedere a un grande volume di dati dal gateway dati locale, un singolo nodo del gateway dati locale può diventare un collo di bottiglia nella gestione di un volume così elevato di richieste.

Un singolo nodo del gateway dati locale può essere sufficiente per gestire 200 o meno connessioni simultanee. Tuttavia, se tutte queste connessioni simultanee stanno eseguendo query attivamente, altre richieste finiscono per attendere una connessione disponibile.

Per informazioni su come garantire che il tuo gateway dati locale sia scalabile in base al volume di dati e richieste, vai a Monitorare e ottimizzare le prestazioni del gateway dati locale.

Considerazioni specifiche per il database SQL di Azure

Le app canvas possono connettersi al database SQL di Azure usando il connettore SQL Server. Una causa comune di problemi di prestazioni quando si usa il database SQL di Azure è la selezione del livello sbagliato per i requisiti aziendali.

Il database SQL di Azure è disponibile in diversi livelli di servizio, con varie funzionalità per soddisfare i diversi requisiti aziendali. Per ulteriori informazioni sui livelli, passa alla documentazione del database SQL di Azure.

Con richieste di dati pesanti, le risorse nel livello selezionato possono subire limitazioni una volta raggiunto il valore di soglia. Tale limitazione compromette le prestazioni della successiva serie di query.

Verifica il livello di servizio del database SQL di Azure. Un livello inferiore comporterebbe alcune limitazioni e vincoli. Dal punto di vista delle prestazioni, CPU, velocità effettiva di I/O e latenza sono importanti. Di conseguenza, ti consigliamo di controllare periodicamente le prestazioni del database SQL e verifica se l'utilizzo delle risorse supera la soglia. Ad esempio, SQL Server locale normalmente imposta la soglia di utilizzo della CPU intorno al 75%.

Considerazioni sulle prestazioni per il connettore SharePoint

Puoi usare il connettore SharePoint per creare app usando i dati di Microsoft Lists. Puoi anche creare app canvas direttamente dalla visualizzazione elenco. Esaminiamo i problemi di prestazioni e le risoluzioni comuni quando si usa un'origine dati SharePoint con le app canvas.

Troppe colonne di ricerca dinamica

SharePoint supporta vari tipi di dati, tra cui le ricerche dinamiche come Persona, Gruppo, e Calcolato. Se un elenco definisce troppe colonne dinamiche, ci vuole più tempo per manipolare queste colonne dinamiche in SharePoint prima di restituire dati al client che esegue l'app canvas.

Non abusare delle colonne di ricerca dinamica in SharePoint. Questo uso eccessivo può comportare un sovraccarico evitabile e aggiuntivo sul lato SharePoint per la manipolazione dei dati. Puoi invece ad esempio utilizzare le colonne statiche per mantenere gli alias di posta elettronica o i nomi delle persone.

Colonna immagine e allegato

La dimensione di un'immagine e il file allegato possono contribuire a una risposta lenta durante il recupero sul client.

Esamina l'elenco e assicurati che siano state definite solo le colonne necessarie. Il numero di colonne nell'elenco influisce sulle prestazioni delle richieste di dati. Questo effetto è dovuto ai record abbinati oppure i record fino ai limiti delle righe di dati definiti vengono recuperati e ritrasmessi al client con tutte le colonne definite nell'elenco, indipendentemente dal fatto che l'app li utilizza tutti o meno.

Per eseguire query solo sulle colonne utilizzate dall'app, abilita la funzionalità Selezione colonna esplicita come descritto in precedenza in questo articolo.

Elenchi ampi

Se disponi di un elenco di grandi dimensioni con centinaia di migliaia di record, è consigliabile suddividere l'elenco in partizioni o dividerlo in più elenchi in base a parametri come le categorie o la data e l'ora.

Ad esempio, i tuoi dati possono essere archiviati in elenchi diversi su base annuale o mensile. In questo caso, puoi progettare l'app per consentire a un utente di selezionare una finestra temporale e recuperare i dati all'interno di tale intervallo.

In un ambiente controllato, il benchmark delle prestazioni ha dimostrato che le prestazioni delle richieste OData rispetto a Microsoft Lists o SharePoint è fortemente correlato al numero di colonne nell'elenco e al numero di righe recuperate (limitato dal limite di righe di dati per le query non delegabili). Un numero inferiore di colonne e l'impostazione del limite di righe di dati inferiore possono migliorare le prestazioni di un'app canvas.

Nel mondo reale, tuttavia, le app sono progettate per soddisfare determinati requisiti aziendali. Potrebbe non essere semplice o rapido ridurre il limite delle righe di dati o il numero di colonne in un elenco. Tuttavia, ti consigliamo di monitorare le richieste OData sul lato client e di ottimizzare il limite delle righe di dati per le query non delegabili e il numero di colonne nell'elenco.

Considerazioni sulle prestazioni quando si utilizza Dataverse come origine dati

Quando usi Microsoft Dataverse come origine dati, le richieste di dati vanno direttamente all'istanza dell'ambiente, senza passare per Gestione API di Azure. Maggiori informazioni: Flusso di chiamate dati durante la connessione a Microsoft Dataverse

Suggerimento

Quando vengono utilizzate tabelle personalizzate in Dataverse, potrebbe essere necessaria una configurazione di sicurezza aggiuntiva per consentire agli utenti di visualizzare i record con le app canvas. Maggiori informazioni: Concetti relativi alla sicurezza in Dataverse, Configurare la sicurezza degli utenti per le risorse in un ambiente e Ruoli e privilegi di sicurezza

Un'app canvas connessa a Dataverse può funzionare lentamente se esegue script client pesanti come Filtra per o JOIN sul lato client anziché sul lato server.

Utilizza le visualizzazioni di Dataverse quando possibile. Una visualizzazione con i criteri di join o filtro richiesti aiuta a ridurre il sovraccarico dell'utilizzo di un'intera tabella. Ad esempio, se hai bisogno di unire le tabelle e filtrare i loro dati, puoi definire una vista unendole e definendo solo le colonne desiderate. Quindi, puoi usare questa visualizzazione nella tua app che crea questo sovraccarico sul lato server per join/filtro invece che sul lato client.Questo metodo non solo riduce le operazioni extra, ma anche la trasmissione dei dati. Per informazioni sulla modifica del filtro e dei criteri di ordinamento, vai a Modificare criteri di filtro.

Considerazioni sulle prestazioni per il connettore Excel

Il connettore Excel fornisce la connettività da un'app canvas ai dati in una tabella in un file Excel. Questo connettore presenta limitazioni rispetto ad altre origini dati, ad esempio funzioni delegabili limitate, che limitano l'app canvas a caricare i dati dalla tabella solo fino a 2000 record. Per caricare più di 2.000 record, partiziona i dati in tabelle dati diverse come altre origini dati.

Diamo un'occhiata ai problemi di prestazioni comuni quando si usa Excel come origine dati per le app canvas e come risolverli.

Troppe tabelle di dati e grandi dimensioni dei dati

Le prestazioni di un'app possono essere lente quando utilizza un file Excel con troppe tabelle di dati o tabelle di dati contenenti un'enorme quantità di dati su più colonne. Un file Excel non è un database relazionale o un origine dati che fornisce funzioni delegabili. Power Apps deve prima caricare i dati dalle tabelle di dati definite, quindi utilizza funzioni come Filter, Sort, JOIN, Group By, e Search.

Troppe tabelle di dati, con un numero elevato di righe e colonne, influiscono sulle prestazioni dell'app e sul sovraccarico lato client perché ogni tabella di dati deve essere manipolata all'interno dell'heap JS. Questo effetto fa sì che l'app consuma più memoria sul lato client.

Per assicurarti che la tua app non venga influenzata da questo problema, definisci solo le colonne necessarie nella tabella dati in un file Excel.

Transazioni pesanti

Excel non è un sistema di database relazionale. Qualsiasi modifica da un'app viene gestita da Excel allo stesso modo di un utente che modifica i dati in un file Excel. Se l'app ha un numero elevato di letture e meno operazioni CRUD, potrebbe funzionare bene. Tuttavia, se l'app effettua transazioni pesanti, può influire negativamente sulle prestazioni dell'app.

Non esiste un valore soglia specifico per il numero di transazioni poiché dipende anche dai dati manipolati. Anche molti altri aspetti influiscono sulle prestazioni dell'app, come il sovraccarico di rete o il dispositivo dell'utente.

Se disponi di dati di sola lettura, puoi importarli nell'app in locale invece di caricarli da origine dati. Per le app aziendali, utilizza invece origini dati quali Dataverse, SQL Server o SharePoint.

Dimensioni file

Puoi scegliere tra una vasta gamma di opzioni di archiviazione nel cloud con capacità di archiviazione variabile o configurabile per il file Excel. Tuttavia, un singolo file Excel di grandi dimensioni con tutte le tabelle definite in un file aggiunge un sovraccarico aggiuntivo per l'app durante il download del file e la lettura dei dati da caricare sul lato client.

Invece di utilizzare un file di grandi dimensioni, dividi i dati in più file Excel con tabelle di dati minime. Quindi connettiti a ciascun file solo quando ne hai bisogno. In questo modo, il caricamento dei dati dalla tabella dati avviene in frammenti, riducendo il sovraccarico di molte tabelle o set di dati di grandi dimensioni.

Percorso del file

La posizione geografica dell'origine dati e la distanza dalle posizioni dei client può causare un collo di bottiglia delle prestazioni per l'app e indurre latenza di rete. Questo effetto può amplificarsi quando un client per dispositivi mobili ha una larghezza di banda limitata per la connettività.

È meglio mantenere il file vicino agli utenti finali (o alla maggior parte degli utenti destinatari globali) in modo che il file possa essere scaricato rapidamente.

Passaggi successivi

Suggerimenti e procedure consigliate per migliorare le prestazioni dell'app canvas

Vedi anche

Comprendere le fasi di esecuzione dell'app canvas e il flusso di chiamata
Origini comuni di prestazioni lente per un'app canvas
Problemi comuni e soluzioni per Power Apps
Risoluzione dei problemi di avvio per Power Apps

Nota

Puoi indicarci le tue preferenze di lingua per la documentazione? Partecipa a un breve sondaggio. (il sondaggio è in inglese)

Il sondaggio richiederà circa sette minuti. Non viene raccolto alcun dato personale (Informativa sulla privacy).