Levinud jõudlusprobleemid ja lahendused

Lõuendirakendusi saate koostada andmeallikate massiivi kasutades. Valige andmeallikas ja konnektor vastavalt ärivajadustele ja stsenaariumidele, mille jaoks te rakendust kujundate. Suurettevõtterakenduste jaoks on andmeallikas soovitatav Microsoft Dataverse seetõttu, et see pakub mitmeid jõudluse eeliseid. Rakenduste jaoks, mille tehingute arv on väike, võite kasutada ükskõik millist olemasolevat andmeallikat oma keskkonnas.

Rakenduse jõudluse kaalutlustel mõelge kasutajate arvule, kes kasutavad rakendust peale selle avaldamist; loomise, toomise, värskendamise ja kustutamise (CRUD) kannete mahule; andme interaktsiooni tüübile; geograafilisele juurdepääsule; ja seadmetele, millega kasutajad rakendust kasutavad.

Selles artiklis saate teada mõne kõige levinuma jõudlusega seotud probleemi kohta, mis võivad muuta lõuendirakendused aeglaseks ja kuidas neid lahendada. See teave aitab teil parandada rakenduse jõudlust edendades nii äriplaani ja kasvu.

Alustame mõne levinud jõudlusprobleemidega, mis ilmnevad olenemata kasutatavast konnektorist. Hilisemates jaotistes saate teavet mitmesuguste konnektorite jaoks spetsiifiliste jõudlusprobleemide ja lahenduse kohta.

Enne alustamist veenduge, et mõistate lõuendirakenduste käivitamise faase ja andmekõnede voogu. Lugege ka lõuendirakenduse aeglaste jõudluse levinumaid allikaid et saada teavet levinud lõksude kohta, mida saate vältida lõuendirakenduste kujundamisel või värskendamisel.

Mahukad andmekogumid laadivad erinevatele platvormidele aeglaselt

Rakenduse jõudlus võib erineda, kui laadite suuri andmekogumeid erinevatele platvormidele, nagu iOS või Android. See variatsioon juhtub sellepärast, et igal platvormil on erinevad võrgunõuded. Näiteks võib lubatud samaaegsete võrgu päringute arv erineda sõltuvalt platvormist. See erinevus võib suurte andmehulkade korral andmete laadimise aega oluliselt mõjutada.

Soovitame laadida ainult need andmed, mis on vaja ekraanil kohe kuvada. Muude andmete jaoks, jaotage ja salvestage vahemällu oma andmed. Lisateave: Nõuanded ja parimad tavad, kuidas parandada lõuendirakenduse jõudlust

Kätte saadud liiga palju veerge

Soovitame valida ainult rakenduse jaoks vajalikud veerud. Lisades rohkem (või kõik) veerud anmeallikast laeb alla kõik andmeveerud. See tegevus toob kaasa palju võrgust pealt kuuldud kõnesid ja seetõttu suure mälukasutuse kliendi seadmes. See probleem võib mobiilsideseadmetega kasutajaid veelgi enam mõjutada, kui võrgu läbilaskevõime on piiratud või kui seadme mälu või pärandprotsessori mälu on piiratud.

Näiteks kui sa kasutad Dataverse oma rakenduse andmeallikana, tee kindlaks, et oled võimaldanud üksikasjalikud veeruvalikud funktsiooni. See funktsioon võimaldab Power Apps -il piirata andmete toomist ainult rakenduses kasutatavate veergudeni.

Üksikasjaliku veeruvaliku funktsiooni sisselülitamiseks lõuendirakenduses, avage Sätted > Eelseisvad funktsioonid > Eelvaade ja lülitage sisse Üksikasjalik veeruvalik lüliti.

Pärandibrauserid ei ole toetatud

Kasutajated, kes kasutavad mittetoetatud või pärandbrausereid, võivad kogeda jõudlusprobleeme. Veenduge, et kasutajad kasutavad ainult toetatud brausereid lõuendirakenduste käivitamiseks.

Geograafilise kauguse põhjustatud aeglane jõudlus

Keskkonna geograafiline asukoht ja kasutajate kaugus andmeallikast võivad mõjutada jõudlust.

Soovitame seda, et teie keskkond asuks kasutajate ligidal. Kuigi Power Apps kasutab Azure'i sisu edastamise võrku sisu jaoks, saavad andmekõned andmed siiski andmeallikast. Mõnes muus geograafilises kohas paiknev andmeallikas võib rakenduse jõudlust negatiivselt mõjutada.

Liigne geograafiline kaugus mõjutab jõudlust erinevalt, nt latentsus, piiratud läbilaskevõime, väiksem läbilaskevõime või paketikadu.

Lubatud loend pole konfigureeritud

Veenduge, et nõutud teenuste URL-id pole blokeeritud või et ned on lisatud tulemüüri lubatud loendisse. Täieliku loendi kõigi teenuse URL-ide kohta, mille jaoks peab Power Apps lubama, minge Kohustuslikud teenused.

Kasuta mitte-delegeeritavaid funktsioone ja ebasobivat andmerea limiiti mitte-delegeeritavate päringute jaoks

Delegeeritavad funktsioonid delegeerivad andmete töötlemise andmeallikale, vähendades kliendipoolset ballasti. Kui delegeerimine pole võimalik, saate piirata andmerea limiiti mitteeraldatavatel päringutel, nii et serveripõhisest ühendusest tagastatud read jäävad optimaalseks.

Mitteeraldatavate funktsioonide kasutamine ja ebasobiv mitteeraldatavate päringute andmerea limiit lisab andmeülekandele ballasti. See ballast põhjustab kliendile saadud andmete manipulatsiooni JS kuhjale . Kasutage rakenduse jaoks alati, kui see on saadaval, eraldustega funktsioone ja kasutage mitteeraldatavate päringute puhul optimaalset andmete rea limiiti.

Lisateavet leiate: Kasuta delegeerimist, Delegeerimise ülevaade

OnStart sündmus nõuab häälestust

OnStart sündmus töötab avalduse laadimise ajal. Suurte andmehulkade nõudmine rakenduse atribuudi funktsioonide abil OnStart põhjustab rakenduse aeglase laadimise. Kuva, mis sõltub suurel määral juhtelementidest ja teisel ekraanil määratletud väärtustest, mõjutab aeglane ekraani navigeerimine.

Järgmistes jaotistes kirjeldatakse mõnda kõige levinumatest probleemidest, mida on nendes olukordades kogetud.

Palju nõudmiseid OnStart sündmusele põhjustab rakenduse aeglast käivitumist

Ettevõttes võib andmenõuete maht keksesse andmeallikasse viia serveri kitsaskohtade või ressursikonfliktini.

Kasutage vahemälumehhanismi andmenõuete optimeerimiseks. Paljud kasutajad võivad kasutada ühte rakendust, mille tulemuseks on kasutaja kohta mitu andmenõuet, mis jõuavad serveri lõpp-punktideni. Need andmenõuded võivad olla kohaks, kus võib toimuda kitsaskoht või neeldumine.

Tugevate skriptide põhjustatud latentsus OnStart sündmuses

Rasked skriptid OnStart sündmusel on üks levinumaid vigu lõuendirakenduste kujundamisel. Peaksite hankima ainult neid andmeid, mida vajate rakenduse käivitamiseks.

Optimeerige valem OnStart sündmuses. Näiteks saate mõne funktsiooni teisaldada atribuudile OnVisible . Sel viisil saate lasta rakendusel kiiresti alustada ja muud sammud võivad rakenduse avanemise ajal jätkuda.

Lisateave: Atribuudi OnStart optimeerimine

Kliendipoolne mälusurve

Oluline on kontrollida lõuendirakenduse mälu kasutust, kuna enamuse ajast töötab rakendus mobiilseadmetes. Mälu erandid kuhjas on kõige tavalisem põhjus sellele, miks lõuendirakendus mõningates seadmetes kokku jookseb või hangub.

JavaScripti (JS) kuhi võib ulatuda piirini, kuna klient töötleb raskeid skripte veergude lisamiseks, ühendamiseks, filtreerimiseks, sortimiseks või rühmitamiseks. Enamikul juhtudel võib kliendi kuhja mälust väljas olemise erand käivitada rakenduse krahhi või hanguda.

Kasutades andmeid allikatest nagu Dataverse või SQL Server, saad kasutada Vaade objekti kindlustamaks selle, et ühinemine, filtreerimine, rühmitamine toimuks serveris- ja mitte kliendipoolel. See meetod vähendab kliendi ballast skriptimist selliste toimingute puhul.

Kui kliendi-rasked toiminguid, nagu ÜHINE või Rühmita juhtuvad kliendipoolel 2000 või enama kirjega andmehulgas, siis objektid hulgas suurenevad, mille tulemuseks on mälulimiitide ületamine.

Arendaja tööriistad lubavad enamikes brauserites profiilida mälu. See aitab teil visualiseerida kuhja suurust, dokumente, sõlmesid ja kuulajaid. Profiili rakenduse jõudlust kasutades brauserit, nagu kirjeldatud Microsoft Edge (Chromiumi) Arendustööriistade ülevaates. Vaadake stsenaariumeid, mis ületavad JS kuhja mäluläve. Lisateave: Mäluprobleemide lahendamine

Jõudluse kaalutlused SQL Serveri ühendajale

AQL Serveri kohapealseks või Azure SQL Andmebaasiga ühendamiseks võite kasutada SQL Serveri ühendajat Power Apps -ile. Selles jaotises kirjeldatakse levinud jõudlusega seotud probleeme ja lahendusi selle konnektori kasutamise kohta lõuendirakenduse jaoks. Lisateave: SQL Serveriga ühenduse loomine Power Apps, Lõuendirakenduse loomine Azure'i SQL-i andmebaasist

Vaadakem levinud jõudlusprobleeme ja lahendusi SQL Serveri konnektori kasutamise kohta lõuendirakenduste jaoks.

N+1 päring

Galeriid, mis genereerivad serveritele liiga palju taotlusi, põhjustavad N+1 päringuprobleeme. N+1 päringu probleem on üks kõige tavalisemaid kogetud probleeme Galerii juhtelemendi kasutamisel.

Probleemi vältimiseks kasutage vaata objekte SQL tagaserveris või muutke kasutajaliidese stsenaariumeid.

Tabeliuuringud indekseerimistulemuse asemel

Rakendus võib aeglustada, kui rakenduse kasutatavad funktsioonid käivitavad andmebaasis päringuid, mille tulemuseks on tabeliuuringud, mitte indekseerimistulemus. Rohkem teavet: Vihjed, Tabel SKÄNNEERI ja Indeks OTSI

Selliste probleemide lahendamiseks kasutage valemis Algab mitte SEES . SQL-andmeallikas puhul on Algab operaatori tulemuseks indekseerimistulemus, kuid SEES operaatori tulemuseks on indekseerimis- või tabeliscan.

Aeglased päringud

Aeglaseid päringuid ja indekseid saate profiilida ja häälestada SQL-andmebaasis. Näiteks, kui valem saab andmed koos laskuva järjestusega (DESC) mõnes kindlas veerus, siis sortimisveerul peaks olema laskuva järjestusega indeks. Registrivõti loob vaikimisi kasvava (ASC) järjestuse.

Saate ka andmenõuete URL aadresse kontrollida. Näiteks järgmine andmetaotluse lõigend (osaline OData nõue) küsib SQL-ilt 500 kirjet, mis vastavad veeru Väärtusele ja järjestuvad ID kahanevas järjestuses.

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

See aitab mõista indeksi nõudeid sarnaste päringutingimuste katmiseks. Kui veerus ID on indeks laskuvas järjestuses, siis päring sooritatakse kiiremini.

Vaadake aeglaste päringute täitmisplaani ja veenduge, et tabeli või registri kontroll oleks olemas. Jälgi iga üleliigset kulu võtmeotsingu käivitusplaanis.

Lisateave:

• Jälgi ja häälesta sooritust
• Jõudluse jälgimine Päringusalve abil
• Laiendatud sündmuste ülevaade

Andmebaasi ressursi vähendamine

Veenduge, et andmeallikas—SQL-andmebaasis—ei oleks ressursi konflikti, nt protsessori kitsaskohti, I/O-konflikti, mälurõhku ega tempDB konflikti. Samuti kontrollige lukke, ooteid, blokeeringuid ja päringu ajalõppe.

Raske klient või üleliigsed nõudmised

Rakendus, mis käitab rühma-, filtreerimis-, või LIITUmistoiminguid kliendipool kasutab kliendi seadmetes protsessori- ja mäluressursse. Sõltuvalt andmete mahust võib nende toimingute jaoks vaja olla rohkem kliendipoolset skriptimisaega, suurendadades kliendi JS-kuhja mahtu. See probleem suureneb iga kohapealse andmeallikas puhul, kuna iga otsinguandmete nõue liigub andmeallikasse andmetee kaudu.

Sellistes olukordades kasutage SQL-andmebaasi objekti Kuva toimingute jaoks Rühmitusalus, Filtreerimisalus või JOIN . Vaated saavad kasutada valikulisi veerge ja eemaldada ebavajalikke veerge suurte andmetüüpidega nagu NVARCHAR(MAX), VARCHAR(MAX) ja VARBINARY(MAX).

Kliendile edastatud andmemaht

Vaikimisi kuvab lõuendirakendus andmeid, kasutades saadaolevaid andmebaasiobjektide tabeleid või vaateid. Kõigi veergude toomine tabelist võib põhjustada aeglast reageeringut, eriti suurte andmetüüpide, nagu NVARCHAR(MAX) kasutamisel.

Suurte andmesummade klientidele edastamine võtab aega. Selle edastuse tulemuseks on pikemad skriptimisajad, kui kliendipoolses JS kuhjas on suuri andmekoguseid, nagu on kirjeldatud käesolevas artiklis eelnevalt.

Kliendile edastatava teabe mahu vähendamiseks kasutage rakenduse jaoks nõutavate konkreetsete veergudega vaateid ja veenduge, et selge veeruvalik on lubatud, nagu on eelnevalt kirjeldatud käesolevas artiklis.

Kaaluge spetsiifilist kuni SQL Serverit kohapeal

SQL Serveri konnektorit kasutava lõuendirakenduse jõudlust koos kohapealse andmelüüsiga võib see mitmel viisil mõjutada. Selles lõigus on loendatud tüüpilised jõudlusprobleemid ja lahendused, mis on spetsiifilised kasutades kohapealseid andmebaasi allikaid.

Ebaterve kohapealne andmelüüs

Organisatsioonid saavad defineerida mitmeid sõlmi kohapealse andmeanalüüsi jaoks. Kui isegi üks sõlmedest on kättesaamatu, ei tagasta päringud vigastele sõlmedele tulemusi ülevaatliku aja jooksul, või võivad need põhjustada mõne aja ootamist "kättesaamatuid" tõrketeateid.

Veenduge, et kõik kohapealsed andmelüüsi sõlmed on terved ja konfigureeritud, nii et sõlmede ja SQL-i eksemplari vahel oleks minimaalne võrgu latentsus.

Kohapealse andmelüüsi asukoht

Andmelüüs nõuab võrgunõudeid kohapealsetele andmeallikatele, et interpreteerida OData nõudeid. Näiteks andmete kogum peab aru saama andmetabeli skeemist, et tõlkida OData taotlused SQL-i andmete iduaalseks keeleks (DML). Täiendavad üldkulud lisatakse, kui andmelüüs on konfigureeritud eraldi asukohas, kus andmelüüsi ja SQL-i eksemplari vahel on suur võrgu latentsusaeg.

Ettevõtluskeskkonnas on soovitatav, et sul on skaleeritav andmelüüsi kogum kui nõutakse raskeid andmeid. Kontrolli kui palju ühendusi on loodud andmelüüside sõlmede ja SQLi eksemplari vahele.

Kontrollides kattuvaid ühendusi kohapealses andmelüüsis või SQL eksemplaris, saab su organisatsioon tuvastada koah, kus andmelüüs vajab väljaskaleerimist ja kui mitme sõlmega.

Adnmelüüsi mastaapsus

Kui arvate, et pääsete juurde suurele hulgale kohapealse andmelüüsi andmetele, võib vaid üks sõlm kohapealses andmelüüsis osutuda nii suuremahulise nõude käsitlemisel kitsaskohaks.

Üksainus kohapealse andmelüüsi sõlm võib olla piisav, et 200 või vähema samaaegse ühendusega tegelemiseks. Kui aga kõik need kattuvad ühendused käitavad aktiivselt päringuid, ootavad muud taotlused saadaolevat ühendust.

Teabe saamiseks selle kohta, et teie kohapealse andmelüüsi skaalad vastavad andmemahule ja päringutele, minge Jälgi ja optimeeri kohapealse andmelüüsi talitlust.

Kaaluge spetsiifilist kuni Azure SQL Andmebaasi

Lõuendirakendused saavad Azure'i SQL-andmebaasiga ühenduse luua SQL Serveri konnektori abil. Levinud jõudluse probleemide põhjus Azure SQL-andmebaasi kasutamisel on vale järgu valimine teie ärinõuete jaoks.

Azure SQL Andmebaas on kättesaadav erinevatel teenindustasemetel, erinevates võimsustes, mis sobivad erinevate ärinõudmistega. Lisateavet tasemete kohta leiate Azure SQL Andmebaasi dokumentatsioon.

Raskete andmenõuete puhul võidakse teie valitud ressursid kohe pidurdada, kui läveväärtus on kätte jõudnud. Selline ahenemine seab ohtu jõudluse järgmises päringutekogumis.

Kontrolli Azure SQL Andmebaasi teenusetaset. Madalamal järgul on mõned piirangud ja tõkked. Jõudluse vaatenurgast on CTU, I/O tootlikkus ja latentsus olulised. Seetõttu soovitame teil aeg-ajalt kontrollida SQL-andmebaasi jõudlust ja kontrollida, kas ressursikasutus ületab läve. Näiteks määrab kohapealne SQL Server tavaliselt CPU kasutamise läveks umbes 75 protsenti.

Jõudluse kaalutlused SharePoint ühendajale

Võite kasutada SharePoint’i konnektorit rakenduste loomiseks, kasutades andmeid Microsoft loendist. Samuti saate luua lõuendirakendust otse loendivaatest. Vaadakem levinud jõudlusprobleeme ja lahendusi SharePoint -i andmeallika kasutamise kohta lõuendirakenduste jaoks.

Liiga palju dünaamilisi otsinguveerge

SharePoint toetab erinevaid andmetüüpe, sealhulgas ka dünaamilisi otsinguid nagu Isik, Gruppja Arvestatud. Kui loend määratleb liiga palju dünaamilisi veerge, võtab nende dünaamiliste veergude käsitsemine SharePoint’is rohkem aega enne kui andmed tagastatakse kliendile, kes käitab lõuendirakendust.

Ära kasuta liiga palju dünaamilisi otsinguveerge SharePoint -is. Selle ülekasutamine võib põhjustada välditavat ülekulu SharePoint poolel andmete manipulatsiooniks. Selle asemel võite kasutada staatilisi veerge, et säilitada näiteks meilisõnumite nimesid või inimeste nimesid.

Pildiveerg ja manus

Pildi ja manustatud faili maht võib klientrakendusse toomisel kaasa aidata aeglasele reageeringule.

Vaadake üle oma loend ja veenduge, et vaid olulised veerud oleks määratletud. Veergude arv loendis mõjutab andmetaotluste jõudlust. See on sellepärast, et ühtivad kirjed või kirjed, mis on määratletud andmerea piiranguteni, tuuakse ja edastatakse tagasi kliendile koos kõigi määratletud veergudega loendist—isegi kui rakendus neid kõiki ei kasuta.

Kui soovite päringut teha ainult rakenduses kasutatavate veergude kohta, lubage selge veeruvaliku funktsiooni nagu on käesolevas artiklis eelnevalt kirjeldatud.

Suured loendid

Kui teil on suur loend, mis sisaldab sadade tuhandete kirjetega, kaaluge loendi jaotamist või selle tükeldamist mitmeks loendiks, võttes aluseks näiteks kategooriad või kuupäeva ja kellaaja.

Näiteks võivad teie andmed olla talletatud erinevatesse loenditesse aasta või kuu lõikes. Sellisel juhul saate rakenduse kujundada nii, et kasutaja saaks valida ajaakna ja tuua andmed selles vahemikus.

Kontrollitud keskkonnas on jõudluse etalon tõestanud, et OData päringute jõudlus võrreldes Microsoft loendite ja SharePoint loendite suhtes on tugevalt seotud veergude arvuga loendis ja toodavate ridade arvuga (piiratud andmerea limiidiga mittedelegeeritavates päringutes). Väiksema arvu veergude ja väiksema andmereapiiri sättega saab lõuendirakendust paremini teostada.

Päris elus on rakendused disainitud vastama teatudärilistele nõudmistele. Andmerea arvu või loendi veergude arvu vähendamine loendis ei pruugi olla kiire ega lihtne. Soovitame teil siiski jälgida OData taotlusi kliendipoolselt ning häälestada mitteerastatavate päringute andmerea limiiti ja loendi veergude arvu.

Jõudluse kaalutlused kasutades Dataverse andmeallikana

Kui kasutate seda Microsoft Dataverse andmeallikas, lähevad andmepäringud otse keskkonnaeksemplari ilma Azure'i API halduse kaudu läbimata. Lisateave: Andmekõne voog ühenduse loomisel Microsoft Dataverse

Dataverse -i ühendatud lõuendirakendus võib töötada aeglaselt kui see käitleb kliendirasket skriptimist nagu Filtreeri või ÜHENDA serveripoolse asemel kliendi pool.

Kasuta Dataverse -i vaadet kui võimalik. Vaade koos nõutud ühenduse või filtriga aitab vähendada üldkulusid kasutades tervet tabelit. Kui peate näiteks tabelid ühendama ja nende andmeid filtreerima, saate määratleda vaate ühendades need ja määratledes ainult need veerud, mida vajate. Seejärel saate kasutada seda vaadet oma rakenduses, mis loob kliendipoolse üldkulu asemel serveripoolse üldkulu liitumis-/filtritoimingu jaoks.See meetod vähendab mitte ainult lisatoiminguid, vaid ka andmeedastust. Teabe jaoks filtri- ja sorteerimiskriteeriumi redigeerimisest, mine Redigeeri filtrikriteerium.

Jõudluse kaalutlused Exceli ühendajale

Exceli ühendaja pakub ühenduvust lõuendirakendusest Exceli faili tabeli andmeteni. Sellel ühendajal on võrreldes teiste andmeallikatega—-iga näiteks piiratud delegeeritavad funktsioonid—mis piiravad lõuendirakendusel laadida andmeid tabelist ainult kuni 2000 kirjeni. Selleks, et laadida rohkem kui 2000 kirjet, jaotage oma andmed erinevatesse andmetabelitesse kui lisa andmeallikad.

Vaadakem levinud jõudlusprobleeme, mis tekivad, kui kasutada Excelit andmeallikana lõuendirakendusele ja kuidas neid lahendada.

Liiga palju andmetabeleid ja suured andmekogumid

Rakendus võib töötada aeglaselt, kui kasutab Exceli faili, milles on liiga palju andmetabeleid või andmetabeleid, mis sisaldavad tohutusuurt andmemahtu, mis ulatub üle mitme veeru. Exceli fail pole relationaalne andmebaas ega andmeallikas, mis pakub delegeerimisfunktsioone. Power Apps peab esmalt laadima andmed määratletud andmetabelist ja seejärel kasutab funktsioone, nagu Filtreeri, Sordi, LIITU, Rühmita ja Otsi.

Liiga paljude andmetabelite olemasolu koos liiga paljude ridade ja veergudega mõjutab rakenduse jõudlust ja kliendipoolset ülekulu sest iga andmetabel peab olema töödeldud JS kuhjas. See mõju viib ka rakenduse kliendipoolse mälu suuremahõivamiseni.

Tagamaks, et see probleem teie rakendust ei mõjuta, määratlege Exceli failis andmetabelis ainult vajalikud veerud.

Rasked kanded.

Excel pole relationaalne andmebaasisüsteem. Mis tahes rakenduse muudatusi haldab Excel samamoodi, nagu kasutaja muudaks andmeid Exceli failis. Kui rakendusel on väga palju lugemisi, kuid vähem CRUD-toiminguid, võib see hästi toimida. Kui aga rakendus teeb liidtehinguid, võib see rakenduse jõudlusele negatiivselt mõjuda.

Tehingute arvu jaoks pole mingit kindlat läveväärtust, kuna see sõltub ka andmetest, mida käsitsetakse. Rakenduse jõudlust mõjutavad ka mitmed muud aspektid, nagu võrgu ülekulu või kasutaja seade.

Kui sul on ainult lugemiseks mõeldud andmed, saad sa selliseid andmeid importida rakendusse lokaalselt, selle asemel, et laadida neidandmeallikast. Ettevõtlusrakenduste jaoks kasuta selle asemel andmeallikaid nagu Dataverse, SQL Server või SharePoint .

Faili maht

Võid valida suure hulga pilvemälu võimaluste vahel, mis varieeruvad—või konfigureeruvad—ruumi mahuga Exceli tabeli failis. Kui aga teil on üks suur Exceli fail, kus kõik tabelid selles failis on määratletud, lisab see rakendusele lisa ülekulu faili allalaadimise ajal ja loeb kliendipool laaditavaid andmeid.

Ühe suure faili kasutamise asemel tükeldage andmed minimaalsete andmetabelitega Exceli failideks. Looge iga failiga ühendus ainult siis, kui vajate seda. Sel viisil toimub andmete laadimine andmetabelist tükk-tüki haaval, vähendades arvukate tabelite või suurte andmehulkade ilmnemist.

Faili asukoht

Andmeallika geograafiline asukoht ja selle kaugus kliendi asukohast võib põhjustad arakenduse jõudluse kitsaskoha ja aidata kaasa võrgu latentsusele. See mõju võib saada amplifitseeritud, kui mobiilikliendi läbilaskevõimel on piiratud ühenduvus.

Faili on parem hoida kasutajate (või enamiku kasutajate, kui teil on globaalne sihtrühm) lähedal, nii et faili saaks kiiresti alla laadida.

Järgmised etapid

Näpunäiteid ja parimaid tavasid lõuendirakenduste jõudluse parendamiseks

Vt ka

Lõuendirakenduse käivitamisfaaside ja andmevoo mõistmine
Levinumad allikad lõuendirakenduse väheses jõudluses
Levinud probleemid ja lahendused Power Apps jaoks
Käivitamisprobleemide tõrkeotsing Power Apps