Probleme și rezoluții obișnuite privind performanța aplicației proiectate pe pânză

Puteți crea aplicații proiectate pe pânză utilizând o gamă diversă de surse de date. Alegeți sursa de date și un conector bazat pe nevoile și scenariile companiei pentru care proiectați aplicația. Pentru aplicațiile enterprise, Microsoft Dataverse este sursă de date recomandat, deoarece oferă mai multe beneficii de performanță. Pentru aplicațiile cu un număr mic de tranzacții, puteți folosi orice alte surse de date disponibile din mediul dvs.

Pentru considerentele de performanță ale unei aplicații, țineți cont numărul de utilizatori care vor folosi aplicația când a fost publicată; volumul tranzacțiilor de creare, preluare, actualizare și ștergere (CRUD); tipul de interacțiuni de date; accesul geografic; și tipurile de dispozitive deținute de utilizator.

În acest articol, veți afla despre unele dintre cele mai frecvente probleme de performanță care pot face ca aplicațiile proiectate pe pânză să ruleze încet, și cum să le rezolvați. Aceste informații vă vor ajuta să îmbunătățiți performanța aplicației, având în vedere planul de business și creșterea.

Vom începe cu unele dintre problemele de performanță obișnuite ce apar indiferent de conectorul utilizat. În secțiunile ulterioare, veți afla despre problemele de performanță și rezoluțiile mai specifice pentru diferiți conectori.

Înainte de a începe, asigurați-vă că înțelegeți fazele de execuție ale aplicației proiectate pe pânză și fluxul de apeluri de date. De asemenea, citiți surse obișnuite de performanță lentă pentru o aplicație proiectată pe pânză pentru a afla despre capcanele obișnuite pe care le puteți evita în timp ce proiectați sau actualizați aplicații proiectate pe pânză.

Seturi mari de date se încarcă încet pe diferite platforme

Performanța unei aplicații poate varia atunci când încărcați seturi mari de date pe diferite platforme, cum ar fi iOS sau Android. Această variație apare din cauza limitărilor diferite ale cererii de rețea pe fiecare platformă. De exemplu, numărul de solicitări de rețea simultane permise poate fi diferit în funcție de platformă. Această diferență poate avea un impact major asupra timpului de încărcare a datelor pentru seturi de date mari.

Vă recomandăm să încărcați doar datele pe care trebuie să le afișați imediat pe ecran. Pentru alte date, paginați și transferați datele în cache. Mai multe informații: Sfaturi și cele mai bune practici pentru a îmbunătăți performanța aplicației proiectate pe pânză

Prea multe coloane regăsite

Vă recomandăm să selectați numai coloanele care sunt necesare pentru aplicație. Adăugând mai multe (sau toate) coloanele dintr-o sursă de date, se descarcă toate datele din coloane. Această acțiune are ca rezultat un număr mare de apeluri de rețea și, prin urmare, o utilizare mare a memoriei în dispozitivul clientului. Această problemă poate afecta utilizatorii cu dispozitive mobile mult mai mult dacă lățimea de bandă a rețelei este limitată sau dacă un dispozitiv are o memorie limitată sau un procesor vechi.

De exemplu, dacă utilizați Dataverse ca sursă de date pentru aplicația dvs., asigurați-vă că ați activat caracteristica de selectare explicită a coloanelor. Această caracteristică permite Power Apps să restricționeze recuperarea datelor numai pentru coloanele utilizate în aplicație.

Pentru a activa funcția explicită de selectare a coloanelor din aplicația proiectată pe pânză, accesați Setări > Caracteristici viitoare > Previzualizare, apoi activați comutatorul Selecție explicită a coloanei.

Browsere neacceptate sau moștenire

Utilizatori care utilizează browsere neacceptate sau moștenite pot resimți probleme de performanță. Asigurați-vă că utilizatorii folosesc numai browserele acceptate pentru rularea aplicațiilor proiectate pe pânză.

Performanță lentă datorită distanței geografice

Amplasarea geografică a mediului și distanța sursei de date față de utilizatori poate afecta performanța.

Vă recomandăm ca mediul dvs. să fie situat aproape de utilizatori. Deși Power Apps utilizează Rețeaua de distribuire a conținutului Azure pentru conținut, apelurile de date primesc în continuare datele de la sursa de date. O sursă de date situată într-o altă locație geografică poate afecta negativ performanța aplicației.

Distanța de localizare geografică excesivă afectează performanța în diferite moduri, cum ar fi latența, randamentul redus, lățimea de bandă mai mică sau pierderea de pachete.

Lista de permisiuni nu este configurată

Asigurați-vă că adresele URL de serviciu necesare nu au fost blocate sau au fost adăugate în lista de permisiuni din firewall. Pentru o listă completă a tuturor adreselor URL de serviciu ce trebuie să fie permise pentru Power Apps, accesați Servicii necesare.

Utilizarea funcțiilor ce nu pot fi delegate și a limitelor neadecvate a rândurilor de date pentru interogări ce nu pot fi delegate

Funcțiile ce pot fi delegate deleagă prelucrarea datelor către sursa de date, minimizând efortul pe partea clientului. Atunci când delegarea nu este posibilă, puteți restricționa limita rândurilor de date pentru interogările ce nu pot fi delegate, astfel încât numărul de rânduri returnate de la o conexiune bazată pe server să rămână optim.

Utilizarea funcțiilor ce nu pot fi delegate și a limitelor inadecvate de rânduri de date pentru interogări ce nu pot fi delegate adăugă un efort suplimentar pentru transferul de date. Acest efort duce la manipularea datelor primite către JS heap de pe partea clientului. Asigurați utilizarea de funcții ce pot fi delegate pentru aplicație ori de câte ori sunt disponibile și utilizați limita optimă de rânduri de date pentru interogări ce nu pot fi delegate.

Mai multe informații: Folosire delegare, Prezentare generală a delegării

Evenimentul OnStart necesită reglare

Evenimentul OnStart rulează atunci când aplicația se încarcă. Apelarea unor cantități mari de date folosind funcțiile din proprietatea OnStart a aplicației va face ca aplicația să se încarce încet. Un ecran care este puternic dependent de controale și valori definite pe un alt ecran va fi afectat prin navigarea lentă a ecranului.

Următoarele secțiuni descriu unele dintre cele mai frecvente probleme întâmpinate în aceste situații.

Număr mare de apeluri în evenimentul OnStart care determină pornirea lentă a aplicației

Într-o întreprindere, volumul de apeluri de date către o sursă de date centrală poate conduce la blocări ale serverului sau la disputarea resurselor.

Utilizați un mecanism cache pentru a optimiza apelurile de date. O singură aplicație poate fi utilizată de mulți utilizatori, ducând la multiple apeluri de date per utilizator care ajung la punctele finale ale serverului. Aceste apeluri de date pot fi un loc în care poate apărea blocajul sau limitarea.

Latență la evenimentul OnStart din cauza scripturilor complexe

Scripturile complexe din evenimentul OnStart sunt una dintre cele mai frecvente greșeli la proiectarea aplicațiilor proiectate pe pânză. Ar trebui să obțineți doar datele necesare pentru ca aplicația să înceapă.

Optimizați formula într-un eveniment OnStart. De exemplu, puteți muta unele funcții în proprietatea OnVisible. În acest fel puteți lăsa aplicația să înceapă rapid, iar alți pași pot continua în timp ce aplicația se deschide.

Mai multe informații: Optimizați proprietatea OnStart

Sfat

Vă recomandăm să utilizați proprietatea App.StartScreen deoarece simplifică lansarea aplicației și crește performanța aplicației.

Presiune pe memorie pe partea clientului

Este important să verificați consumul de memorie al aplicației proiectate pe pânză deoarece de cele mai multe ori aplicația rulează pe dispozitive mobile. Excepțiile de memorie din stivă sunt cea mai probabilă cauză pentru o eroare fatală sau blocare („încetinire”) pe anumite dispozitive.

O stivă JavaScript (JS) poate atinge limita din cauza scripturilor complexe care rulează pe partea clientului pentru adăugare, asociere, filtrare, sortare sau grupare de coloane. În majoritatea cazurilor, o excepție de memorie insuficientă din stivă într-un client poate face ca aplicația să genereze o eroare fatală sau să se blocheze.

Când utilizați date din surse precum Dataverse sau SQL Server, puteți utiliza un obiect Vizualizare pentru a vă asigura că îmbinarea, filtrarea, gruparea sau sortarea au loc pe partea serverului și nu a clientului. Această abordare reduce efortul pentru client pentru scriptarea acestor acțiuni.

Dacă operațiunile complexe pentru client, cum ar fi ASOCIERE sau Grupare după, au avut loc pe partea clientului cu un set de date care are 2000 de înregistrări sau mai mult, obiectele din stivă vor crește, rezultând depășirea limitelor memoriei.

Instrumentele pentru dezvoltatori pentru majoritatea browserelor vă permit să configurați memoria. Vă ajută la vizualizarea dimensiunii stivei, documentelor, nodurilor și ascultătorilor. Profilați performanța aplicației utilizând un browser, așa cum este descris în Microsoft Edge (Chromium) Prezentare generală a instrumentelor pentru dezvoltatori. Verificați scenariile care depășesc pragul de memorie al stivei JS. Mai multe informații: Remediați problemele de memorie

Considerente privind performanța pentru conectorul SQL Server

Puteți folosi conectorul SQL Server pentru Power Apps pentru a vă conecta la SQL Server local sau la baza de date Azure SQL. Această secțiune descrie problemele obișnuite legate de performanță și rezolvările pentru utilizarea acestui conector pentru o aplicație proiectată pe pânză. Mai multe informații: Conectare la SQL Server din Power Apps, Creare aplicație proiectată pe pânză din baza de date SQL Azure

Notă

Deși această secțiune face referire la conectorul SQL Server pentru probleme de performanță și rezolvări, majoritatea recomandărilor se aplică și la utilizarea oricărui tip de bază de date—precum MySQL sau PostgreSQL—ca sursa de date.

Să aruncăm o privire la problemele de performanță și rezolvările obișnuite la utilizarea conectorului SQL Server pentru aplicațiile proiectate pe pânză.

Interogare N+1

Galeriile care generează prea multe solicitări către servere produc probleme de interogare N+1. Problema de interogare N+1 este una dintre cele mai frecvent întâlnite probleme la utilizarea controlului Galerie.

Pentru a evita problema, utilizați obiectele de vizualizare în backend-ul SQL sau modificați scenariile interfeței cu utilizatorul.

Scanarea tabelului în loc de căutarea indexului

O aplicație poate încetini dacă funcțiile utilizate de aplicație rulează interogări în baza de date care au ca rezultat scanări de tabele în loc de căutări în index. Mai multe informații: Sugestii, SCANARE tabel și CĂUTARE index

Pentru a rezolva astfel de probleme, utilizați StartsWith în loc de IN în formulă. Cu o sursă de date SQL, operatorul StartsWith are ca rezultat o căutare în index, dar operatorul IN duce la o scanare a indexului sau tabelului.

Interogări lente

Puteți profila și regla interogări și indexuri lente în baza de date SQL. De exemplu, dacă o formulă obține anumite date cu ordine descendentă (DESC) pe o anumită coloană, acea coloană de sortare ar trebui să aibă un index cu ordine descendentă. Tasta Index creează în mod implicit o ordine ascendentă (ASC).

De asemenea, puteți verifica adresa URL a solicitărilor de date. De exemplu, următorul fragment de solicitare de date (apel OData parțial) solicită SQL să returneze 500 de înregistrări care corespund coloanei Valoare ordonate după ID în ordine descendentă.

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

Acest lucru ajută la înțelegerea cerințelor indexului pentru a acoperi condiții de solicitare similare. În acest exemplu, când coloana ID are un index cu ordine descrescătoare, interogarea va fi efectuată mai rapid.

Verificați planul de execuție al interogărilor lente pentru a vedea dacă există vreo scanare de tabel sau de index. Monitorizați orice costuri excesive ale căutării de chei în planul de execuție.

Informații suplimentare:

• Monitorizați și reglați pentru performanță
• Monitorizarea performanței utilizând magazinul de interogări
• Prezentare generală evenimente extinse

Disputarea resurselor bazei de date

Asigurați-vă că sursă de date—bază de date SQL—nu are disputări de resurse, cum ar fi blocaje ale procesorului, dispută I/O, presiune pe memorie sau dispută tempDB. Verificați și dacă există blocări, așteptări, impasuri și expirări pentru interogări.

Sfat

Utilizați reglarea automată pentru informații despre potențiale probleme de performanță pentru interogare, soluții recomandate și pentru remedierea automată a problemelor identificate.

Client integral sau solicitări excesive

O aplicație care rulează operațiuni Grupare după, Filtrare după sau ASOCIERE pe partea clientului utilizează resurse de procesor și memorie de pe dispozitivele client. În funcție de dimensiunea datelor, aceste operațiuni ar putea necesita mai mult timp de scriptare pe partea clientului, crescând dimensiunea JS heap pentru client. Această problemă crește pentru o sursă de date locală, deoarece fiecare apel de căutare date se deplasează la sursa de date prin gateway-ul de date.

În astfel de situații, utilizați obiectul Vizualizare în baza de date SQL pentru operațiunile Group By, Filter by sau JOIN . Vizualizările pot utiliza coloane selective și pot elimina coloanele inutile cu tipuri de date mari, cum ar fi NVARCHAR(MAX), VARCHAR(MAX) și VARBINARY(MAX).

Sfat

Această abordare ajută și la tratarea problemei de interogare N+1.

Dimensiunea datelor transferate clientului

În mod implicit, o aplicație proiectată pe pânză afișează date prin folosirea de tabele sau vizualizări din obiectele de bază de date disponibile. Preluarea tuturor coloanelor dintr-un tabel poate duce la un răspuns lent, mai ales atunci când se utilizează tipuri de date mari, cum ar fi NVARCHAR(MAX).

Transferul unor cantități mari de date către clienți necesită timp. Acest transfer are ca rezultat și mai mult timp de scriptare atunci când există cantități mari de date în stiva JS de partea clientului, așa cum a fost descris anterior în acest articol.

Pentru a reduce dimensiunea datelor transferate către client, utilizați vizualizări cu coloanele specifice necesare pentru aplicație și asigurați-vă că este activată selecția explicită a coloanelor, așa cum a fost descris anterior în acest articol.

Considerente specifice SQL Server local

Performanța unei aplicații proiectate pe pânză folosind conectorul SQL Server cu un gateway de date local ar putea fi afectată în diferite moduri. Această secțiune listează problemele de performanță și rezoluțiile comune specifice utilizării unei surse de bază de date locale.

Gateway de date local nesănătos

Organizațiile pot defini mai multe noduri pentru gateway-uri de date locale. Chiar dacă unul dintre noduri nu este accesibil, solicitările de date către nodul nesănătos nu vor returna rezultatul într-un interval de timp acceptabil, sau ar putea genera mesaje de eroare „inaccesibil” după un timp de așteptare.

Asigurați că toate nodurile gateway de date local sunt sănătoase și sunt configurate cu o latență minimă a rețelei între noduri și instanța SQL.

Locația gateway-ului de date local

O gateway de date necesită apeluri de rețea către sursele de date locale pentru a interpreta solicitările OData. De exemplu, gateway-ul de date trebuie să înțeleagă schema tabelului de date pentru a traduce cererile OData în instrucțiunile limbajului de manipulare a datelor SQL (DML). Se adaugă cheltuieli suplimentare atunci când gateway-ul de date este configurat într-o locație separată, cu latență ridicată a rețelei între gateway-ul de date și instanța SQL.

Într-un mediu de întreprindere, este recomandat să aveți un cluster de gateway de date scalabil atunci când sunt așteptate solicitări de date complexe. Verificați câte conexiuni sunt stabilite între nodurile gateway-ului de date și instanța SQL.

Verificând conexiunile simultane într-un gateway de date local sau o instanță SQL, organizația dvs. poate identifica punctul în care gateway-ul de date trebuie să fie scalat și cu câte noduri.

Scalabilitatea gateway-ului de date

Dacă vă așteptați să accesați un volum mare de date de la gateway-ul de date local, doar un singur nod al gateway-ului de date local poate deveni un blocaj la tratarea unui volum atât de mare de solicitări.

Un singur nod al gateway-ului de date local ar putea fi suficient pentru a trata 200 sau mai puține conexiuni simultane. Totuși, dacă toate aceste conexiuni simultane execută interogări în mod activ, alte cereri ajung să aștepte o conexiune disponibilă.

Pentru informații despre asigurarea scalării gateway-ului dvs. de date local în conformitate cu volumul de date și solicitările, accesați Monitorizare și optimizare performanță gateway de date local.

Considerente specifice bazei de date Azure SQL

Aplicațiile proiectate pe pânză se pot conecta la baza de date SQL Azure prin utilizarea conectorului SQL Server. O cauză comună a problemelor de performanță la utilizarea bazei de date SQL Azure este selectarea nivelului greșit pentru cerințele afacerii dvs.

Baza de date SQL Azure este disponibilă în diferite niveluri de servicii, cu capabilități variate corespunzând diferitelor cerințe de business. Pentru mai multe informații despre niveluri, accesați Documentația bazei de date Azure SQL.

Cu solicitări intense de date, resursele de pe nivelul pe care îl selectați pot fi restrânse imediat ce valoarea pragului este atinsă. O astfel de restrângere compromite performanța următorului set de interogări.

Verificați nivelul de servicii din baza de date SQL Azure. Un nivel inferior va avea unele limitări și constrângeri. Dintr-o perspectivă de performanță, procesorul, randamentul I/O și latența sunt importante. Ca urmare, vă recomandăm să verificați periodic performanța bazei de date SQL și verificați dacă utilizarea resurselor depășește pragul. De exemplu, serverul SQL local stabilește în mod normal pragul de utilizare a procesorului la aproximativ 75 procente.

Considerente privind performanța pentru conectorul SharePoint

Puteți utiliza conectorul SharePoint pentru a crea aplicații folosind date din listele Microsoft. De asemenea, puteți crea aplicații proiectate pe planșă direct din vizualizarea listei. Să aruncăm o privire la problemele de performanță și rezolvările obișnuite pentru utilizarea unei surse de date SharePoint cu aplicațiile proiectate pe pânză.

Prea multe coloane de căutare dinamice

SharePoint acceptă diferite tipuri de date, inclusiv căutări dinamice precum Persoană, Grup, și Calculat. În cazul în care o listă definește prea multe coloane dinamice, este nevoie de mai mult timp pentru a manipula aceste coloane dinamice din SharePoint înainte de a returna date clientului care rulează aplicația proiectată pe planșă.

Nu folosiți în exces coloanele de căutare dinamică din SharePoint. Această utilizare excesivă poate rezulta într-o suprasolicitare care poate fi evitată și suplimentară pe partea SharePoint pentru manipularea datelor. În schimb, puteți utiliza coloane statice pentru a păstra aliasurile de e-mail sau numele persoanelor, de exemplu.

Coloană imagine și atașare

Dimensiunea unei imagini și un fișier atașat pot contribui la un răspuns lent în timp ce sunt recuperate către client.

Examinați lista și asigurați-vă că au fost definite doar coloanele necesare. Numărul de coloane din listă afectează performanța solicitărilor de date. Acest lucru apare deoarece înregistrările potrivite sau înregistrările până la limitele de rând de date definite, sunt preluate și transmise înapoi clientului cu toate coloanele definite în lista—chiar dacă aplicația nu le folosește pe toate.

Pentru a interoga numai coloanele utilizate de aplicație, activați caracteristica de selectare explicită a coloanelor, așa cum a fost descrisă anterior în acest articol.

Liste mari

Dacă aveți o listă mare cu sute de mii de înregistrări, luați în considerare partiționarea listei sau împărțirea listei în mai multe liste pe baza parametrilor precum categoriile sau data și ora.

De exemplu, datele dvs. ar putea fi stocate în liste diferite, anual sau lunar. Într-un astfel de caz, puteți proiecta aplicația pentru a permite unui utilizator să selecteze un interval de timp și să preia datele din intervalul respectiv.

Într-un mediu controlat, testarea de performanță a dovedit că performanța solicitărilor OData pentru listele SharePoint sau Microsoft este puternic legată de numărul de coloane din listă și de numărul de rânduri preluate (limitat de limita rândului de date pentru interogări ce nu se pot delega). Folosirea a mai puține coloane și a unei setări mai mici pentru limita rândurilor de date pot face o aplicație proiectată pe pânză să aibă performanțe mai bune.

Totuși, în lumea reală, aplicațiile sunt concepute pentru a îndeplini anumite cerințe de business. Ar putea să nu fie rapid sau simplu să reduceți limita rândului de date sau numărul de coloane dintr-o listă. Cu toate acestea, vă recomandăm să monitorizați solicitările OData pe partea clientului și să reglați limita rândului de date pentru interogările ce nu pot fi delegate și numărul de coloane din listă.

Considerente privind performanța pentru utilizarea Dataverse ca sursă de date

Când folosiți Microsoft Dataverse ca sursă de date, cererile de date merg direct la instanța de mediu, fără a trece prin Azure API Management. Mai multe informații: Fluxul de apel de date la conectarea la Microsoft Dataverse

Sfat

Când se utilizează tabele personalizate în Dataverse, ar putea fi necesară o configurație de securitate suplimentară pentru ca utilizatorii să poată vizualiza înregistrările cu aplicații proiectate pe pânză. Mai multe informații: Concepte de securitate în Dataverse, Configurați securitatea utilizatorului pentru resurse într-un mediu, și Roluri de securitate și privilegii

O aplicație proiectată pe pânză conectată la Dataverse ar putea funcționa lent dacă rulează scripturi complexe pentru client cum ar fi Filtrare după sau ASOCIERE pe partea client în loc pe partea serverului.

Utilizați vizualizările Dataverse când este posibil. O vizualizare cu criteriile necesare de asociere sau filtrare ajută la reducerea efortului de utilizare a unui întreg tabel. De exemplu, dacă trebuie să alăturați tabelele și să le filtrați datele, puteți definiți o vizualizare alăturându-le și definiți doar coloanele de care aveți nevoie. Apoi, puteți utiliza această vizualizare în aplicația dvs., care creează acest efort pe partea serverului pentru operația de asociere/filtrare în loc de pe partea clientului.Această metodă reduce nu numai operațiunile suplimentare, ci și transmisia de date. Pentru informații despre editarea criteriilor de filtrare și sortare, accesați Editați criteriile de filtrare.

Considerente privind performanța pentru conectorul Excel

Conectorul Excel oferă conectivitate de la o aplicație proiectată pe pânză la datele dintr-un tabel într-un fișier Excel. Acest conector are limitări în comparație cu alte surse de date—de exemplu, funcții ce se pot delega limitate—ce restricționează aplicația proiectată pe pânză la încărcarea datelor din tabel numai până la 2000 de înregistrări. Pentru a încărca mai mult de 2000 de înregistrări, partiționați datele dvs. în diferite tabele de date ca surse de date diferite.

Să aruncăm o privire la problemele de performanță obișnuite la utilizarea Excel ca sursa de date pentru aplicațiile proiectate pe pânză, și modul de rezolvare pentru acestea.

Prea multe tabele de date și dimensiuni mari de date

O aplicație poate funcționa lent când folosește un fișier Excel care are prea multe tabele de date sau tabele de date care conțin o cantitate imensă de date pe mai multe coloane. Un fișier Excel nu este o bază de date relațională sau o sursă de date care oferă funcții ce pot fi delegate. Power Apps trebuie să încarce mai întâi datele din tabelele de date definite și apoi să utilizeze funcții precum Filtrare, Sortare, ASOCIERE, Grupare după, și Căutare.

Când se folosesc prea multe tabele de date, cu multe rânduri și coloane, este afectată performanța aplicației și efortul pe partea clientului, deoarece fiecare tabel de date trebuie manipulat în JS heap. Acest efect duce și consumarea de către aplicație a unei cantități mai mari de memorie pe partea clientului.

Pentru a vă asigura că aplicația dvs. nu este afectată de această problemă, definiți doar coloanele de care aveți nevoie în tabelul de date dintr-un fișier Excel.

Tranzacții complexe

Excel nu este un sistem de baze de date relațional. Orice modificare dintr-o aplicație este gestionată de Excel în același mod ca și când un utilizator ar schimba datele într-un fișier Excel. Dacă aplicația are un număr mare de citiri, dar mai puține operațiuni CRUD, aceasta ar putea funcționa bine. Cu toate acestea, dacă aplicația efectuează tranzacții complexe, aceasta poate afecta negativ performanța aplicației.

Nu există o valoare prag specifică pentru numărul de tranzacții, deoarece depinde și de datele ce sunt manipulate. Mai multe alte aspecte afectează și performanța aplicației, cum ar fi efortul în rețea sau dispozitivul utilizatorului.

Dacă aveți date numai în citire, puteți importa astfel de date în aplicație în loc să le încărcați din sursa de date. Pentru aplicațiile de întreprindere, utilizați în schimb surse de date precum Dataverse, SQL Server sau SharePoint.

Dimensiune fișier

Puteți alege dintr-o gamă largă de opțiuni de stocare în cloud cu capacitate de stocare variabilă—sau configurabilă—pentru fișierul Excel. Cu toate acestea, folosirea unui singur fișier Excel mare, cu toate tabelele definite în acel fișier, adaugă efort suplimentar pentru aplicație în timp ce descărcă fișierul și citește datele de încărcat pe partea clientului.

În loc să utilizați un fișier mare, împărțiți datele în mai multe fișiere Excel cu tabele de date minimale. Apoi conectați-vă la fiecare fișier numai când aveți nevoie de el. În acest fel, încărcarea datelor din tabelul de date se întâmplă în fragmente, reducând efortul pentru folosirea mai multor tabele sau a unui set de date mare.

Locație fișier

Localizarea geografică a sursei de date și distanța față de locațiile clienților poate duce la un blocaj de performanță comun pentru aplicație și poate induce o latență a rețelei. Acest efect poate deveni amplificat când un client mobil are lățimea de bandă limitată pentru conectivitate.

Este mai bine să păstrați fișierul aproape de utilizatori (sau majoritatea utilizatorilor, dacă aveți o audiență globală), astfel încât fișierul să poată fi descărcat rapid.

Pașii următori

Sfaturi și cele mai bune practici pentru a îmbunătăți performanța aplicației proiectate pe pânză

Consultați și

Explicații despre fazele de execuție ale aplicației proiectate pe pânză și fluxul apelurilor de date
Surse comune de performanță lentă pentru o aplicație proiectată pe pânză
Probleme și soluții comune pentru Power Apps
Depanarea problemelor de pornire pentru Power Apps

Notă

Ne puteți spune care preferințele dvs. lingvistice pentru documentație? Răspundeți la un chestionar scurt. (rețineți că acest chestionar este în limba engleză)

Chestionarul va dura aproximativ șapte minute. Nu sunt colectate date personale (angajament de respectare a confidențialității).