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 de întreprindere, Microsoft Dataverse este sursa de date recomandată, deoarece asigură 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 aplicație creată pe planșă fazele de execuție și fluxul apelurilor de date. De asemenea, citiți Surse obișnuite de performanță lentă pentru un aplicație creată pe planșă pentru a afla despre capcanele comune pe care le puteți evita în timp ce proiectați sau actualizați aplicațiile planșă de lucru.

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

Performanța unei aplicații poate varia atunci când se încarcă 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 cache datele dvs. Mai multe informații: Sfaturi și cele mai bune practici pentru a îmbunătăți performanța aplicație creată pe planșă

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 funcția de selecție explicită a coloanei . Această caracteristică permite Power Apps să restricționeze recuperarea datelor numai pentru coloanele utilizate în aplicație.

Pentru a activa funcția de selecție explicită a coloanei pe aplicație creată pe planșă, accesați Setări>Funcții viitoare>versiune preliminară și apoi activați comutatorul Selectarea 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 browsere acceptate pentru rularea aplicațiilor planșă de lucru.

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 servicii care trebuie permise pentru Power Apps, accesați Serviciile 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 delegabile delegă procesarea datelor către sursă de date, minimizând supraîncărcarea din 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 nedelegabile și a limitelor inadecvate de rânduri de date pentru interogările nedelegabile aduc supraîncărcare suplimentară transferului de date. Această suprasarcină are ca rezultat manipularea datelor primite către heap-ul JS de 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: Utilizați delegarea, Prezentare generală despre delegare

Evenimentul OnStart necesită reglare

Evenimentul OnStart se rulează când se încarcă aplicația. Apelarea unor cantități mari de date prin utilizarea funcțiilor din OnStart proprietatea a aplicației va face ca aplicația să se încarce lent. 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 de 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 grele de la evenimentul OnStart sunt una dintre cele mai frecvente greșeli la proiectarea aplicațiilor planșă de lucru. 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 acesteia.

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 View pentru a vă asigura că alăturarea, filtrarea, gruparea sau sortarea apare pe partea serverului în loc de partea clientului. Această abordare reduce efortul pentru client pentru scriptarea acestor acțiuni.

Dacă operațiunile aglomerate pentru clienți, cum ar fi JOIN sau Group By au avut loc la nivelul clientului cu un set de date care are 2.000 de înregistrări sau mai mult, obiectele din heap vor crește, rezultând depășirea limitelor de memorie.

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 Prezentarea generală a Instrumentelor pentru dezvoltatori (Chromium). 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 utiliza SQL Server conector pentru Power Apps pentru a vă conecta la SQL Server local sau Azure SQL Baza de date. 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ă.

Notă

Deși această secțiune face referire la conectorul SQL Server pentru probleme de performanță și soluții, majoritatea recomandărilor se aplică și utilizării oricărui tip de bază de date, cum ar fi MySQL sau PostgreSQL, ca sursă 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 interogarea N+1 este una dintre cele mai frecvent întâlnite probleme cu utilizarea controlului Galerie .

Pentru a evita problema, utilizați view objects î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: Sfaturi, SCANARE tabelă și Căutare index

Pentru a rezolva astfel de probleme, utilizați StartsWith în loc de IN în formulă. Cu un SQL sursă de date,, operatorul StartsWith are ca rezultat o căutare de index, dar operatorul IN determină un index sau scanarea 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ătoarea solicitare de date fragment (apel OData parțial) solicită SQL să returneze 500 de înregistrări care corespund coloanei cu Valoare și să ordone după ID în ordine descrescătoare.

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 performanța
• Monitorizarea performanței prin utilizarea Magazinului de interogări
• Prezentare generală a evenimentelor extinse

Disputarea resurselor bazei de date

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

Sfat

Folosiți ajustarea automată pentru informații despre potențialele probleme de performanță a interogărilor, soluții recomandate și pentru a remedia automat problemele identificate.

Client integral sau solicitări excesive

O aplicație care rulează Group By, Filter By sau JOIN operațiunile din partea clientului utilizează procesor și resurse de memorie de la dispozitivele client. În funcție de dimensiunea datelor, aceste operațiuni pot dura mai mult timp de scriptare din partea clientului, mărind dimensiunea heap JS a clientului. 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 din baza de date SQL pentru Group By, a46>Filtrați după operațiuni sau JOIN . Vizualizările pot folosi coloane selective și pot elimina coloanele inutile cu tipuri de date mari, cum ar fi NVARCHAR(MAX), VARCHAR(MAX) a53> și VARBINARY(MAX).

Sfat

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

Dimensiunea datelor transferate către client

Î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 avea ca rezultat o răspuns lentă, mai ales 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, de asemenea, mai mult timp de scriptare atunci când există cantități mari de date în heap-ul JS din partea clientului, după cum a fost descris mai devreme în acest articol.

Pentru a reduce dimensiunea datelor transferate către client, utilizați vizualizările cu coloanele specifice necesare pentru aplicație și asigurați-vă că selectarea explicită a coloanelor este activată, așa cum s-a descris mai devreme î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ă eforturi suplimentare atunci când gateway-ul de date este configurat într-o locație separată cu o 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 cum să vă asigurați că gateway-ul dvs. de date local se scalează în conformitate cu volumul de date și solicitări, accesați Monitorizați și optimizați performanța gateway-ului 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 Azure SQL Documentația bazei de date.

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, local SQL Server setează în mod normal pragul de utilizare a CPU la aproximativ 75 la sută.

Considerente privind performanța pentru conectorul SharePoint

Puteți utiliza SharePoint conectorul pentru a crea aplicații utilizând 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, cum ar fi 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 se datorează faptului că înregistrările potrivite, sau înregistrările până la limitele de rânduri de date definite, sunt preluate și transmise înapoi către client cu toate coloanele definite în listă - chiar dacă aplicația nu le folosește pe toate.

Pentru a interoga numai coloanele utilizate de aplicație, activați funcția de selecție explicită a coloanelor, așa cum a fost descris mai devreme î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, benchmark-ul de performanță a dovedit că performanța solicitărilor OData împotriva listelor Microsoft sau SharePoint este strâns legată de numărul de coloane din listă și de numărul de rânduri care sunt preluate (limitat de limită de rânduri de date pentru interogări nedelegabile). 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 apeluri de date atunci când vă conectați 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 la resursele dintr-un mediu și a19>Roluri și privilegii de securitate

Un aplicație creată pe planșă conectat la Dataverse ar putea să funcționeze lent dacă rulează scripturi abundente pentru clienți, cum ar fi Filtrare prin sau JOIN partea clientului în loc de partea serverului.

Folosiți Dataverse vizualizări 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ă asociați tabele și să filtrați datele acestora, puteți defini o vizualizare unându-le și definiți numai 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țiile suplimentare, ci și transmiterea datelor. Pentru informații despre editarea criteriilor de filtru și sortare, accesați Editați criteriile de filtrare.

Considerente privind performanța pentru conectorul Excel

Conector Excel oferă conectivitate de la un aplicație creată pe planșă la datele dintr-un tabel dintr-un fișier Excel. Acest conector are limitări în comparație cu alte surse de date, de exemplu, funcții delegabile limitate – care limitează aplicație creată pe planșă la încărcarea datelor din tabel doar până la 2.000 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, apoi utilizează funcții precum Filter, Sort, INSCRIERE, Grupați după, și Căutare.

Având prea multe tabele de date cu multe rânduri și coloane afectează performanța aplicației și supraîncărcarea la nivelul clientului, deoarece fiecare tabel de date trebuie manipulat în heap JS. 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

Locația geografică a sursă de date și distanța sa față de locațiile clienților pot duce la un blocaj de performanță pentru aplicație și poate induce 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ție creată pe planșă

Consultați și

Înțelegeți fazele de execuție aplicație creată pe planșă și fluxul apelurilor de date
Surse comune de performanță lentă pentru un aplicație creată pe planșă
Probleme comune și rezoluții pentru Power Apps
Depanarea problemelor de pornire pentru Power Apps