Bežné problémy s výkonom aplikáciám plátna a riešenia
Môžete vytvárať aplikácie plátna pomocou rozmanitých polí zdrojov údajov. Vyberte si zdroj údajov a konektor v závislosti od obchodných potrieb a scenárov, pre ktoré navrhujete aplikáciu. Pre podnikové aplikácie je Microsoft Dataverse odporúčaný zdroj údajov, pretože poskytuje niekoľko výhod v oblasti výkonu. V prípade aplikácií s málo transakciami môžete využívať akékoľvek ďalšie dostupné zdroje údajov vo vašom prostredí.
Z hľadiska výkonnosti aplikácie zvážte počet používateľov, ktorí budú aplikáciu používať po jej zverejnení, objem transakcií CRUD (vytváranie, získavanie, aktualizácia a odstraňovanie), typ dátových interakcií, geografický prístup a druh zariadení používateľa.
V tomto článku sa dozviete o niektorých najbežnejších problémoch s výkonom, vďaka ktorým môžu aplikácie plátna bežať pomaly, a o tom, ako ich vyriešiť. Tieto informácie vám pomôžu zlepšiť výkonnosť aplikácie so zreteľom na váš obchodný plán a rast.
Začneme niektorými z bežných problémov s výkonom, ktoré nastanú bez ohľadu na použitý konektor. V ďalších častiach sa dozviete o problémoch s výkonom a riešeniach špecifických pre rôzne konektory.
Skôr než začnete, uistite sa, že rozumiete fázam spúšťania aplikácie plátna a toku dátových hovorov. Prečítajte si tiež Bežné zdroje pomalého výkonu aplikácie na plátne a dozviete sa o bežných nástrahách, ktorým sa môžete vyhnúť pri navrhovaní alebo aktualizácii aplikácií plátna.
Veľké súbory údajov sa pomaly načítajú na rôznych platformách
Výkon aplikácie sa môže líšiť pri načítavaní veľkých množín údajov na rôznych platformách, ako sú iOS alebo Android. K tejto variácii dochádza z dôvodu rôznych obmedzení sieťových požiadaviek na každej platforme. Napríklad počet povolených súbežných sieťových požiadaviek sa môže líšiť podľa platformy. Tento rozdiel môže mať zásadný vplyv na čas načítania údajov pre veľké množiny údajov.
Odporúčame vám načítať iba údaje, ktoré potrebujete okamžite zobraziť na obrazovke. V prípade ostatných údajov stránkujte a uložte údaje do vyrovnávacej pamäte . Ďalšie informácie: Tipy a osvedčené postupy na zlepšenie výkonu aplikácie canvas
Bolo načítaných príliš veľa stĺpcov
Odporúčame vybrať iba potrebné stĺpce pre aplikáciu. Pridaním ďalších (alebo všetkých) stĺpcov zo zdroja údajov sa stiahnu všetky údaje stĺpcov. Výsledkom tejto akcie je vysoký počet režijných volaní v sieti, a teda vysoké využitie pamäte v klientskom zariadení. Tento problém môže ešte viac ovplyvniť používateľov mobilných zariadení, ak je obmedzená šírka pásma siete alebo ak má zariadenie obmedzenú pamäť alebo starší procesor.
Ak napríklad pre svoju aplikáciu používate Dataverse ako zdroj údajov, uistite sa, že ste povolili funkciu explicitný výber stĺpcov . Táto funkcia umožňuje Power Apps obmedziť získavanie údajov iba pre stĺpce použité v aplikácii.
Ak chcete zapnúť funkciu explicitného výberu stĺpcov v aplikácii plátno, prejdite na Nastavenia>Nadchádzajúce funkcie>verzia Preview a potom zapnite prepínač Explicitný výber stĺpcov .
Nepodporované alebo zastarané prehliadače
Používatelia, ktorí používajú nepodporované alebo staršie prehliadače môžu mať problémy s výkonom. Uistite sa, že používatelia používajú na spúšťanie aplikácií plátna iba podporované prehliadače .
Pomalý výkon z dôvodu geografickej vzdialenosti
Geografické umiestnenie prostredia a vzdialenosť zdroja údajov od koncových používateľov môžu ovplyvniť výkon.
Odporúčame, aby vaše prostredie bolo umiestnené v blízkosti používateľov. Aj keď Power Apps používa pre obsah sieť Azure Content Delivery Network, dátové volania stále získavajú údaje zo zdroja údajov. Zdroj údajov umiestnený na inom geografickom mieste môže nepriaznivo ovplyvniť výkon aplikácie.
Nadmerná geografická vzdialenosť ovplyvňujú výkon rôznymi spôsobmi, ako je napríklad latencia, znížená priepustnosť, nižšia šírka pásma alebo strata paketov.
Zoznam povolení nie je nakonfigurovaný
Zaistite, aby ste neblokovali požadované adresy URL služieb, alebo aby neboli pridané do zoznamu povolených položiek brány firewall. Úplný zoznam všetkých adries URL služieb, ktoré musia byť povolené pre Power Apps, nájdete v časti Požadované služby.
Použitie nedegradovateľných funkcií a neprimeraných limitov riadkov údajov pre nedelegovateľné dotazy
Delegovateľné funkcie delegujú spracovanie údajov na zdroj údajov, čím sa minimalizujú režijné náklady na strane klienta. Ak delegovanie nie je možné, môžete obmedziť limit dátových riadkov pre nedelegovateľné dotazy, aby počet riadkov vrátených zo serverového pripojenia zostal optimálny.
Použitie nedelegovateľných funkcií a nevhodné limity údajových riadkov pre nedelegovateľné dopyty zvyšujú réžiu prenosu údajov. Výsledkom tejto réžie je manipulácia s prijatými údajmi do haldy JS na strane klienta. Zabezpečte, aby ste pre aplikáciu používali delegovateľné funkcie, kedykoľvek sú k dispozícii, a optimálny limit riadku údajov pre nedelegovateľné dotazy.
Ďalšie informácie: Použite delegovanie, Prehľad delegovania
Udalosť OnStart je potrebné vyladiť
Udalosť OnStart sa spúšťa pri načítavaní aplikácie. Volanie veľkého množstva údajov pomocou funkcií vo vlastnosti OnStart aplikácie spôsobí pomalé načítavanie. Obrazovka so silnou závislosťou na ovládacích prvkoch a hodnotách definovaných na inej obrazovke bude ovplyvnená pomalou navigáciou po obrazovke.
V nasledujúcich častiach sú popísané niektoré z najbežnejších problémov, ktoré sa v týchto situáciách vyskytujú.
Vysoký počet volaní v udalosti OnStart, čo spôsobuje pomalý štart aplikácie
V podniku môže objem dátových volaní na centrálny zdroj údajov spôsobiť spomalenie priepustnosti servera alebo spor o prostriedky.
Na optimalizáciu dátových volaní použite mechanizmus vyrovnávacej pamäte . Mnoho používateľov môže používať jednu aplikáciu, čo vedie k veľkému množstvu dátových volaní na používateľa, ktoré sa dostanú do koncových bodov servera. Tieto dátové volania môžu byť miestom, kde sa môže vyskytnúť úzke miesto alebo obmedzenie.
Latencia pri udalosti OnStart z dôvodu ťažkých skriptov
Ťažké skripty na podujatí OnStart sú jednou z najčastejších chýb pri navrhovaní aplikácií na plátne. Mali by ste získať iba údaje potrebné na spustenie aplikácie.
Optimalizujte vzorec v udalosti OnStart . Niektoré funkcie môžete napríklad presunúť do vlastnosti OnVisible . Týmto spôsobom môžete nechať aplikáciu rýchlo spustiť a počas spúšťania aplikácie môžu pokračovať ďalšie kroky.
Viac informácií: Optimalizujte vlastnosť OnStart
Prepitné
Odporúčame použiť vlastnosť App.StartScreen , pretože zjednodušuje spúšťanie aplikácie a zvyšuje jej výkon.
Tlak pamäte na strane klienta
Kontrola spotreby pamäte aplikácií plátna sa stáva dôležitou, pretože aplikácia plátna je väčšinou spustené na mobilných zariadeniach. Výnimky pamäte v heape sú najpravdepodobnejšou príčinou aplikácie plátna, ktorá na určitých zariadeniach zlyháva alebo zamŕza (zablokuje sa).
JavaScript (JS) Heap sa môže dostať na maximum z dôvodu náročných skriptov spustených na strane klienta na pridávanie stĺpcov, pripájanie, filtrovanie, triedenie alebo zoskupovanie. Vo väčšine prípadov môže výnimka nedostatku pamäte v heape klienta spôsobiť zlyhanie alebo zablokovanie aplikácie.
Pri používaní údajov zo zdrojov, ako je Dataverse alebo SQL Server, môžete použiť objekt Zobraziť , aby ste sa uistili, že dôjde k spájaniu, filtrovaniu, zoskupovaniu alebo triedeniu. na strane servera namiesto na strane klienta. Tento prístup znižuje režijné náklady klienta na skriptovanie pre takéto akcie.
Ak sa na strane klienta vyskytli operácie náročné na klienta, ako napríklad JOIN alebo Group By s množinou údajov, ktorá má 2 000 záznamov alebo viac, objekty v halde sa zväčšia, čo vedie k prekročeniu limitov pamäte.
Vývojové nástroje pre väčšinu prehľadávačov vám umožňujú profilovať pamäť. Pomôže vám to vizualizovať veľkosť haldy, dokumenty, uzly a poslucháčov. Profilujte výkon aplikácie pomocou prehliadača, ako je popísané v Microsoft Edge Prehľad nástrojov pre vývojárov (Chromium). Skontrolujte scenáre, ktoré prekračujú prahovú hodnotu pamäte haldy JS. Ďalšie informácie: Opravte problémy s pamäťou
Úvahy o výkone pre konektor SQL Server
Na pripojenie k SQL Serveru lokálny alebo Azure SQL Database môžete použiť konektor SQL Server na Power Apps . Táto časť popisuje bežné problémy a riešenia týkajúce sa výkonu pri používaní tohto konektora pre aplikáciu plátna.
Poznámka
Hoci táto časť odkazuje na konektor SQL Server pre problémy s výkonom a riešenia, väčšina odporúčaní sa vzťahuje aj na používanie akéhokoľvek typu databázy – ako je MySQL alebo PostgreSQL – ako zdroj údajov.
Pozrime sa na bežné problémy s výkonom a ich riešenia pri použití konektora SQL Server pre aplikácie plátna.
N+1 dotaz
Galérie generujúce príliš veľa požiadaviek na servery spôsobujú problémy s dotazom N+1. Problém N+1 dotaz je jedným z najčastejšie sa vyskytujúcich problémov pri používaní ovládacieho prvku Galéria .
Ak sa chcete problému vyhnúť, použite zobrazovacie objekty v back-ende SQL alebo zmeňte scenáre používateľského rozhrania.
Skenovanie tabuľky namiesto hľadania indexu
Aplikácia sa môže spomaliť, ak funkcie, ktoré používa, spúšťajú dotazy v databáze, čo vedie k prehľadaniu tabuľky namiesto hľadania indexu. Ďalšie informácie: Rady, SKENOVANIE tabuľky a HĽADANIE indexu
Na vyriešenie takýchto problémov použite StartsWith namiesto IN vo vzorci. S SQL zdroj údajov má operátor StartsWith za následok vyhľadávanie indexu, ale operátor IN má za následok indexové alebo tabuľkové skenovanie.
Pomalé dotazy
Môžete profilovať a vyladiť pomalé dotazy a indexy v databáze SQL. Ak napríklad vzorec získava údaje so zostupným poradím (DESC) v určitom stĺpci, potom by mal mať tento triediaci stĺpec index v zostupnom poradí. Indexový kľúč predvolene vytvára vzostupné (ASC) poradie.
Môžete tiež skontrolovať adresu URL žiadostí o údaje. Napríklad nasledujúca požiadavka na údaje úryvok (čiastočné volanie OData) žiada SQL, aby vrátil 500 záznamov zodpovedajúcich stĺpcu s hodnotou Hodnota a zoradenie podľa ID v zostupnom poradí.
Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500
To pomáha porozumieť požiadavkám na index, aby sa pokryli podobné podmienky žiadosti. V tomto príklade, ak má stĺpec ID index v zostupnom poradí, dotaz sa vykoná rýchlejšie.
Skontrolujte plán vykonávania pomalých dotazov a zistite, či existuje skenovanie tabuľky alebo indexu. Monitorujte akékoľvek nadmerné náklady na vyhľadávanie kľúčov v pláne spúšťania.
Ďalšie informácie:
Spor o databázové prostriedky
Uistite sa, že zdroj údajov – databáza SQL – nemá žiadne spory o prostriedky, ako sú problémy s procesorom, spory o vstupy a výstupy, tlak na pamäť alebo spory tempDB . Skontrolujte tiež časové limity zámkov, čakaní, zablokovania a dotazov.
Prepitné
Použite automatické ladenie na získanie prehľadu o potenciálnych problémoch s výkonom dotazov, odporúčaných riešeniach a na automatické odstraňovanie zistených problémov.
Silný klient alebo nadmerné požiadavky
Aplikácia spustená Zoskupiť podľa, Filtrovať podľa alebo ZAPOJTE SA operácie na strane klienta využívajú procesor a pamäťové prostriedky z klientskych zariadení. V závislosti od veľkosti údajov môžu tieto operácie na strane klienta trvať viac času na skriptovanie, čím sa zvýši halda JS na klientovi. Tento problém narastá v prípade lokálneho zdroja údajov, pretože každé volanie vyhľadávacích údajov putuje do zdroja údajov cez dátovú bránu.
V takýchto situáciách použite objekt Zobraziť v databáze SQL pre Skupinu podľa, Filtrovať podľa alebo ZAPOJTE SA operácie. Zobrazenia môžu používať selektívne stĺpce a odstraňovať nepotrebné stĺpce s veľkými dátovými typmi, ako napríklad NVARCHAR(MAX), VARCHAR(MAX) a VARBINARY(MAX).
Prepitné
Tento prístup tiež pomáha riešiť N+1 problém s dotazom.
Veľkosť údajov prenesená do klienta
Aplikácia plátna predvolene zobrazuje údaje pomocou tabuliek alebo zobrazení z dostupných databázových objektov. Načítanie všetkých stĺpcov z tabuľky môže viesť k spomaleniu odpoveď, najmä pri použití veľkých dátových typov, ako je NVARCHAR(MAX).
Prenos veľkého množstva údajov klientom chvíľu trvá. Tento prenos má za následok aj dlhší čas na skriptovanie, keď je v halde JS na strane klienta veľké množstvo údajov, ako je popísané vyššie v tomto článku.
Ak chcete znížiť veľkosť údajov prenášaných do klienta, použite zobrazenia so špecifickými stĺpcami požadovanými pre aplikáciu a uistite sa, že je povolený explicitný výber stĺpcov, ako je popísané vyššie v tomto článku.
Úvahy špecifické pre lokálny SQL Server
Výkon aplikácií plátna pomocou konektora SQL Server s lokálnou dátovou bránou môže byť ovplyvnený rôznymi spôsobmi. V tejto časti sú uvedené bežné problémy s výkonom a ich rozlíšenia, ktoré sú špecifické pre použitie zdroja lokálnej databázy.
Lokálna brána údajov v zlom stave
Organizácie môžu definovať viac uzlov pre lokálnu bránu údajov. Aj keď je jeden z uzlov nedostupný, požiadavky na údaje do nezdravého uzla nevrátia výsledok v prijateľnom časovom rámci alebo môžu spôsobiť chybové hlásenia „nedosiahnuteľný“ po chvíli čakania.
Zaistite, aby boli všetky uzly lokálnej brány údajov v poriadku a nakonfigurované s minimálnou latenciou siete medzi uzlami a inštanciou SQL.
Umiestnenie lokálnej brány údajov
Brána údajov vyžaduje na interpretáciu požiadaviek OData sieťové volania do lokálnych zdrojov údajov. Napríklad brána údajov musí porozumieť schéme tabuľky údajov, aby mohla preložiť požiadavky OData do príkazov jazyka SQL Data Manipulation Language (DML). Ak je brána údajov nakonfigurovaná na samostatnom mieste s vysokou latenciou siete medzi dátovou bránou a inštanciou SQL, pridá sa ďalšia réžia.
V podnikovom prostredí sa odporúča mať škálovateľný klaster brány údajov, keď sa očakávajú vysoké požiadavky na údaje. Skontrolujte, koľko spojení je nadviazaných medzi uzlami brány údajov a inštanciou SQL.
Začiarknutím súbežných pripojení v lokálnej bráne údajov alebo v inštancii SQL môže vaša organizácia identifikovať bod, kedy je potrebné bránu údajov škálovať, a o koľko uzlov.
Škálovateľnosť brány údajov
Ak očakávate prístup k veľkému množstvu údajov z lokálnej brány údajov, iba jeden uzol lokálnej brány údajov sa môže stať prekážkou, ktorá spracuje také veľké množstvo požiadaviek.
Jeden uzol lokálnej brány údajov môže stačiť na zvládnutie 200 alebo menej súbežných pripojení. Ak však všetky tieto súbežné pripojenia aktívne vykonávajú dotazy, ostatné požiadavky nakoniec čakajú na dostupné pripojenie.
Informácie o tom, ako zabezpečiť, aby sa vaša lokálny dátová brána škálovala v súlade s objemom dát a požiadaviek, nájdete na Monitorovanie a optimalizácia lokálny výkonu dátovej brány.
Úvahy špecifické pre Azure SQL Database
Aplikácie plátna sa môžu pripojiť k databáze Azure SQL pomocou konektora SQL Server. Bežnou príčinou problémov s výkonom pri používaní databázy Azure SQL je výber nesprávnej úrovne pre vaše obchodné požiadavky.
Azure SQL Database je k dispozícii v rôznych úrovniach služieb s rôznymi schopnosťami vyhovieť rôznym obchodným požiadavkám. Ďalšie informácie o vrstvách nájdete v Dokumentácia k databáze Azure SQL.
Pri veľkých požiadavkách na údaje sa zdroje na vybranej vrstve môžu po dosiahnutí prahovej hodnoty obmedziť. Takéto obmedzenie obmedzuje výkon ďalšej množiny dotazov.
Skontrolujte úroveň služieb Azure SQL Database. Nižšia vrstva bude mať určité obmedzenia a limity. Z hľadiska výkonu sú dôležité priepustnosť CPU, I/O a latencia. Preto odporúčame pravidelne kontrolovať výkon databázy SQL a či využitie prostriedkov nepresahuje prahovú hodnotu. Napríklad lokálny SQL Server normálne nastavuje prah využitia procesora na približne 75 percent.
Úvahy o výkone pre konektor SharePoint
Pomocou SharePoint konektora môžete vytvárať aplikácie pomocou údajov zo zoznamov Microsoft. Môžete tiež vytvárať aplikácie na plátne priamo zo zobrazenia zoznamu . Pozrime sa na bežné problémy s výkonom a ich riešenia pri použití zdroja údajov SharePoint s aplikáciami plátna.
Príliš veľa stĺpcov dynamického vyhľadávania
SharePoint podporuje rôzne typy údajov vrátane dynamických vyhľadávaní, ako napríklad Osoba, Skupina a Vypočítané. Ak zoznam definuje príliš veľa dynamických stĺpcov, manipulácia s týmito dynamickými stĺpcami vo vnútri SharePoint trvá dlhšie pred vrátením údajov klientovi, na ktorom je spustená aplikácia plátna.
Nepoužívajte nadmerne stĺpce dynamického vyhľadávania v SharePoint. Toto nadmerné používanie môže mať za následok režijné náklady na strane SharePoint pre manipuláciu s údajmi, ktorým sa možno vyhnúť. Namiesto toho môžete napríklad použiť statické stĺpce na uchovanie e-mailových aliasov alebo mien ľudí.
Stĺpec s obrázkom a príloha
Veľkosť obrázka a pripojeného súboru môže prispievať k pomalej odozve pri načítaní klientovi.
Skontrolujte svoj zoznam a ubezpečte sa, že boli definované iba potrebné stĺpce. Počet stĺpcov v zozname ovplyvňuje výkonnosť požiadaviek na údaje. Je to preto, že zhodné záznamy alebo záznamy až do definovaných limitov riadkov údajov sa načítajú a prenesú späť klientovi so všetkými stĺpcami definovanými v zozname – aj keď ich aplikácia všetky nepoužíva.
Ak chcete dotaviť iba stĺpce, ktoré používajú aplikácia, povoľte explicitnú funkciu výberu stĺpca, ako je opísané vyššie v tomto článku.
Veľké zoznamy
Ak máte veľký zoznam so stovkami tisíc záznamov, zvážte rozdelenie zoznamu alebo ho rozdeľte do niekoľkých zoznamov na základe parametrov, ako sú kategórie alebo dátum a čas.
Napríklad vaše údaje môžu byť uložené v rôznych zoznamoch ročne alebo mesačne. V takomto prípade môžete navrhnúť aplikáciu a umožniť používateľovi zvoliť časové okno na načítanie údajov v tomto rozsahu.
V rámci kontrolovaného prostredia test výkonu dokázal, že výkon požiadaviek OData voči zoznamom Microsoft alebo SharePoint vo veľkej miere súvisí s počtom stĺpcov v zozname a počtom riadkov, ktoré sa majú načítať (obmedzené hodnotou limit údajových riadkov pre nedelegovateľné dopyty). Vďaka nižšiemu počtu stĺpcov a nižšiemu nastaveniu limitu dátových riadkov môže byť aplikácia plátna výkonnejšia.
V skutočnom svete sú však aplikácie navrhnuté tak, aby spĺňali určité obchodné požiadavky. Zníženie limitu riadkov údajov alebo počtu stĺpcov v zozname nemusí byť rýchle ani jednoduché. Odporúčame však monitorovať požiadavky OData na strane klienta a vyladiť limit údajových riadkov pre nedelegovateľné dotazy a počet stĺpcov v zozname.
Úvahy o výkone pri použití Dataverse ako zdroja údajov
Keď použijete Microsoft Dataverse ako zdroj údajov, idú žiadosti o údaje priamo do inštancie prostredia bez toho, aby prechádzali správou Azure API. Ďalšie informácie: Tok dátových hovorov pri pripájaní k Microsoft Dataverse
Prepitné
Keď sa používajú vlastné tabuľky v Dataverse, aby si používatelia mohli prezerať záznamy pomocou aplikácií plátna, môže byť vyžadovaná ďalšia konfigurácia zabezpečenia. Ďalšie informácie: Bezpečnostné koncepty v Dataverse, Konfigurácia zabezpečenia používateľov na zdroje v prostredí a Úlohy zabezpečenia a privilégiá
Aplikácia plátna pripojená k Dataverse môže fungovať pomaly, ak spúšťa klientsky náročné skriptovanie, ako napríklad Filtrovať podľa alebo JOIN na strane klienta namiesto na strane servera.
Keď je to možné, použite Dataverse zobrazenia . Zobrazenie s požadovanými kritériami pripojenia alebo filtrovania pomáha znižovať réžiu používania celej tabuľky. Ak napríklad potrebujete spojiť tabuľky a filtrovať ich údaje, môžete definovať zobrazenie ich spojením a definovať iba požadované stĺpce. Potom môžete použiť toto zobrazenie vo svojej aplikácii, ktoré vytvorí túto réžiu na strane servera na pripojenie/filtrovanie namiesto na strane klienta. Táto metóda nielenže zredukuje ďalšie operácie, ale aj dátový prenos. Informácie o úprave kritérií filtrovania a triedenia nájdete v časti Upraviť kritériá filtrovania.
Úvahy o výkone pre konektor Excel
konektor programu Excel poskytuje pripojenie z aplikácie plátna k údajom v tabuľke v súbore programu Excel. Tento konektor má v porovnaní s inými zdrojmi údajov obmedzenia – napríklad obmedzené delegovateľné funkcie – ktoré obmedzujú aplikáciu canvas na načítanie údajov z tabuľky len do 2 000 záznamov. Ak chcete načítať viac ako 2 000 záznamov, rozdeľte svoje údaje do rôznych tabuliek údajov ako ďalšie zdroje údajov.
Pozrime sa na bežné problémy s výkonom a ich riešenia pri použití zdroja údajov Excel pre aplikácie plátna a spôsobe ich riešenia.
Príliš veľa tabuliek s údajmi a veľká veľkosť údajov
Aplikácia môže fungovať pomaly, keď používa súbor programu Excel s príliš veľkým počtom údajových tabuliek alebo údajové tabuľky, ktoré majú obrovskú veľkosť údajov v niekoľkých stĺpcoch. Súbor Excel nie je relačná databáza ani poskytovateľ zdroja údajov, ktorý poskytuje delegovateľné funkcie. Power Apps musí najprv načítať údaje z definovaných údajových tabuliek a potom použiť funkcie ako Filter, Zoradiť, Pripojte sa , skupinu , a Vyhľadávanie.
Príliš veľa tabuliek údajov s mnohými riadkami a stĺpcami ovplyvňuje výkon aplikácie a réžiu na strane klienta, pretože s každou tabuľkou údajov je potrebné manipulovať v rámci haldy JS. Tento efekt tiež vedie k tomu, že aplikácia spotrebuje viac pamäte na strane klienta.
Ak chcete zaistiť, aby vaša aplikácia nebola ovplyvnená takýmto problémom, definujte iba nevyhnutné stĺpce v údajovej tabuľke v súbore Excel.
Náročné transakcie
Excel nie je systém relačnej databázy. Akékoľvek zmeny z aplikácie spravuje Excel rovnakým spôsobom ako používateľ, ktorý mení údaje v súbore Excel. Ak má aplikácia vysoký počet prečítaní, ale menej operácií CRUD, môže fungovať dobre. Ak však aplikácia vykonáva ťažké transakcie, môže to nepriaznivo ovplyvniť jej výkon.
Pre počet transakcií neexistuje žiadna špecifická prahová hodnota, pretože to tiež závisí od manipulovaných údajov. Na výkon aplikácie má vplyv aj niekoľko ďalších aspektov, napríklad sieťová réžia alebo zariadenie používateľa.
Ak máte údaje iba na čítanie, môžete ich namiesto aplikácie načítať z aplikácie zdroj údajov a importovať ich lokálne do aplikácie. V prípade podnikových aplikácií použite zdroje údajov, ako sú napr. Dataverse, SQL Server alebo SharePoint namiesto toho.
Veľkosť súboru
Môžete si vybrať zo širokej škály možností cloudového úložiska s rôznou – alebo konfigurovateľnou – kapacitou úložiska pre súbor Excel. Jeden veľký súbor programu Excel so všetkými tabuľkami definovanými v jednom súbore však pridáva ďalšiu réžiu pre aplikáciu pri sťahovaní súboru a načítaní údajov, ktoré sa majú načítať na strane klienta.
Namiesto použitia jedného veľkého súboru rozdeľte údaje do viacerých súborov programu Excel s minimálnymi tabuľkami údajov. Potom sa ku každému súboru pripojte, iba ak to potrebujete. Týmto spôsobom sa načítanie údajov z údajovej tabuľky deje vo fragmentoch, čo znižuje réžiu mnohých tabuliek alebo veľkej množiny údajov.
Umiestnenie súboru
Geografická poloha zdroj údajov a jej vzdialenosť od klientskych umiestnení môže spôsobiť prekážku výkonu aplikácie a vyvolať latenciu siete. Tento efekt sa môže zosilniť u mobilného klienta, ktorý má obmedzenú šírku pásma pre pripojenie.
Je lepšie uchovávať súbor v blízkosti koncových používateľov (alebo väčšiny koncových používateľov v prípade globálnej cieľovej skupiny), aby sa súbor mohol rýchlo stiahnuť.
Ďalšie kroky
Tipy a osvedčené postupy na zlepšenie výkonu aplikácie canvas
Pozrite si tiež:
Pochopte fázy vykonávania aplikácie plátna a toku dátových hovorov
Bežné zdroje pomalého výkonu aplikácie na plátne
Bežné problémy a riešenia pre Power Apps
Riešenie problémov so spustením pre Power Apps