Bežné problémy s výkonom aplikáciám plátna a riešenia

Článok
03/14/2023

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ým zdroj údajov, pretože poskytuje niekoľko výhod 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 ako začnete, uistite sa, že ste porozumeli fázam spúšťania aplikácií plátna a toku dátových volaní. Tiež si prečítajte Spoločné zdroje pomalého výkonu pre aplikácie plátna, kde sa dozviete o bežných úskaliach, 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. Pokiaľ ide o ďalšie údaje, použite stránkovanie a vyrovnávaciu pamäť vašich údajov. Ďalšie informácie: Tipy a osvedčené postupy na zlepšenie výkonu aplikácií plátna

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.

Napríklad, ak používate Dataverse ako zdroj údajov pre svoju aplikáciu, nezabudnite povoliť funkciu Explicitný výber stĺpca. 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átna, prejdite na Nastavenie > Pripravované funkcie > Náhľad a potom zapnite prepínač Explicitný výber stĺpca.

Nepodporované alebo zastarané prehliadače

Používatelia, ktorí používajú nepodporované alebo staršie prehliadače môžu mať problémy s výkonom. Zaistite, aby používatelia používali iba podporované prehliadače na spustenie aplikácií plátna.

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. Pre úplný zoznam všetkých adries URL služieb, ktoré musia byť povolené pre Power Apps, prejdite do 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 minimalizuje réžia 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 funkcií, ktoré nemožno delegovať, a nevhodné limity riadku údajov pre nedelegovateľné dotazy pridáva ďalšiu réžiu pri prenose dát. Táto réžia má za následok manipuláciu s prijatými dátami do JS heap 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žiť delegovanie, Prehľad delegovania

Udalosť OnStart je potrebné vyladiť

Udalosť OnStart sa spustí pri načítaní aplikácie. Volanie veľkého množstva dát pomocou funkcií vo vlastnosti OnStart aplikácie spôsobí pomalé načítanie aplikácie. 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.

Použite mechanizmus vyrovnávacej pamäte a optimalizujte dátové volania. 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

Náročné skripty pri udalosti OnStart sú jednou z najčastejších chýb pri navrhovaní aplikácií plátna. Mali by ste získať iba údaje potrebné na spustenie aplikácie.

Optimalizujte vzorec v udalosti OnStart. Napríklad presuňte niektoré funkcie 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í: Optimalizácia vlastnosti OnStart

Tip

Odporúčame použiť vlastnosť App.StartScreen, pretože zjednodušuje spúšťanie aplikácie a zvyšuje výkon aplikácie.

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žití údajov zo zdrojov ako napr. Dataverse alebo SQL Server, môžete použiť objekt Zobrazenie na zabezpečenie spojenia, filtrovania, zoskupovania alebo triedenia 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 uskutočnili náročné operácie ako JOIN alebo Group By s dátovou množinou s 2000 záznamami alebo viac, objekty v halde sa zvýšia, čo povedie k prekročeniu pamäťových limitov.

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 časti Microsoft Edge (Chromium) prehľad vývojových nástrojov. Skontrolujte scenáre, ktoré prekračujú prahovú hodnotu pamäte haldy JS. Viac informácií: Oprava problémov s pamäťou

Príklad tlaku na pamäť pre aplikáciu z vývojových nástrojov prehliadača.

Úvahy o výkone pre konektor SQL Server

Môžete použiť SQL Server konektor pre Power Apps na pripojenie k lokálnemu serveru SQL Server alebo k databáze Azure SQL. 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. Viac informácií: Pripojenie k serveru SQL Server z Power Apps, Vytvorenie aplikácie plátna z databázy Azure SQL

Poznámka

Aj keď táto časť odkazuje na konektor servera SQL Server z dôvodu problémov s výkonom a ich riešenia, väčšina odporúčaní platí aj pri použití ľubovoľného typu databázy — ako MySQL alebo PostgreSQL — ako zdroja ú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. N+1 problém s dotazom je jedným z najčastejšie sa vyskytujúcich problémov pri používaní ovládacieho prvku Galéria.

Ak sa chcete vyhnúť problémom, použite prezerať objekty v backende 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. Viac informácií: Rady, SKENOVANIE tabuliek a VYHĽADÁVANIE indexov

Na vyriešenie týchto problémov použite StartsWith namiesto IN vo vzorci. Pri použití SQL zdroja údajov je výsledkom operátora StartsWith vyhľadanie indexu; ale výsledkom operátora IN je prehľadávanie indexu alebo tabuľky.

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úci úryvok na požadovanie údajov (čiastočné volanie OData) žiada SQL, aby vrátil 500 záznamov zodpovedajúcich stĺpcu Hodnota s usporiadaním 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

Zaistite, že zdroj údajov — databáza SQL — nemá žiadne rozpory v zdrojoch, ako napríklad úzke miesto procesora, I/O spor, nároky na pamäť alebo spor tempDB. Skontrolujte tiež časové limity zámkov, čakaní, zablokovania a dotazov.

Tip

Použite automatické ladenie na získanie informácií o potenciálnych problémoch s výkonom dotazov, odporúčaných riešení a na automatickú opravu zistených problémov.

Silný klient alebo nadmerné požiadavky

Aplikácia, na ktorej na klientskej strane bežia operácie Zoskupiť podľa, Filtrovať podľa alebo JOIN, využíva procesor a pamäťové prostriedky z klientskych zariadení. V závislosti od veľkosti údajov môžu tieto operácie trvať na klientskej strane viac skriptovacieho času, čím sa zvýši veľkosť JS haldy u klienta. 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 Zoskupiť 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 typmi veľkých údajov, ako sú NVARCHAR(MAX), VARCHAR(MAX) a VARBINARY(MAX).

Tip

Tento prístup tiež pomáha riešiť N+1 problém s dotazom.

Veľkosť dát prenesená klientovi

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 mať za následok pomalú odozvu, najmä pri použití veľkých dátových typov, napríklad NVARCHAR(MAX).

Prenos veľkého množstva údajov klientom chvíľu trvá. Výsledkom tohto prenosu je aj viac skriptovacieho času, keď je v halde JS na strane klienta veľké množstvo údajov popísané skôr v tomto článku.

Ak chcete zmenšiť veľkosť údajov prenášaných na 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 bolo popísané skôr 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). Keď je brána údajov nakonfigurovaná na samostatnom mieste s vysokou latenciou siete medzi bránou údajov a inštanciou SQL, dochádza k ďalšej réžii.

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álna brána údajov škálovala v súlade s objemom údajov a požiadaviek, prejdite na Monitorujte a optimalizujte výkon lokálnej brány údajov.

Ú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 úrovniach nájdete v časti 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 bežne nastavuje prahovú hodnotu využitia CPU na zhruba 75 %.

Úvahy o výkone pre konektor SharePoint

Môžete použiť konektor SharePoint na vytváranie aplikácií pomocou údajov z Microsoft Lists. 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. 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. Tento efekt je spôsobený tým, že sa zhodujú záznamy, alebo sa načítajú záznamy až do definovaných limitov riadkov údajov a prenášajú sa späť do klienta so všetkými stĺpcami definovanými v zozname — bez ohľadu na to, či ich aplikácia používa všetky alebo nie.

Ak chcete dotazovať iba stĺpce, ktoré používa aplikácia, povoľte funkciu explicitného výberu stĺpca, ako bolo popí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 kontrolovanom prostredí výkonový test dokázal, že výkon požiadaviek OData na Microsoft Lists alebo SharePoint úzko súvisí s počtom stĺpcov v zozname a počtom načítaných riadkov (obmedzené hodnotou limit riadku údajov pre nedelegovateľné dotazy). 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. Viac informácií: Tok dátových volaní pri pripájaní k Microsoft Dataverse

Tip

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. Viac informácií: Bezpečnostné koncepty v Dataverse, Konfigurácia zabezpečenia používateľa pre zdroje v prostredí a Roly zabezpečenia a privilégiá

Aplikácia plátna pripojená k Dataverse môže pracovať pomaly, ak spúšťa náročné skriptovanie na strane klienta, ako napríklad Filtrovať podľa alebo PRIPOJIŤ SA na strane klienta namiesto na strane servera.

Použite Zobrazenia Dataverse, keď je to možné. Zobrazenie s požadovanými kritériami pripojenia alebo filtrovania pomáha znižovať réžiu používania celej tabuľky. Napríklad, ak potrebujete spojiť tabuľky a filtrovať ich údaje, môžete definovať zobrazenie ich spojením a definovaním iba požadovaných stĺpcov. 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 znižuje nielen dodatočné operácie, ale aj prenos dát. Informácie o úprave filtra a kritériách triedenia nájdete v časti Úprava kritérií filtrovania.

Úvahy o výkone pre konektor Excel

Excel konektor poskytuje pripojenie z aplikácie plátna k údajom v tabuľke v súbore Excel. Tento konektor má v porovnaní s inými zdrojmi údajov obmedzenia — napríklad obmedzené delegovateľné funkcie — ktoré obmedzujú aplikácii plátna načítať údaje z tabuľky iba 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í najskôr načítať údaje z definovaných tabuliek s údajmi a potom použiť funkcie ako napr. Filtrovať, Triediť, PRIPOJIŤ SA, Zoskupiť podľa a Vyhľadať.

Príliš veľa údajových tabuliek s množstvom riadkov a stĺpcov ovplyvňuje výkon aplikácie a réžiu na strane klienta, pretože s každou údajovou tabuľkou je potrebné manipulovať v rámci JS haldy. 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 ponuky možností cloudového úložiska s rôznou — alebo konfigurovateľnou — úložnou kapacitou 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ť k umiestneniu klientov môže mať za následok zníženie 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 plátna

Pozrite si tiež:

Oboznámenie sa s fázami spúšťania aplikácie plátna a s postupom údajových volaní
Bežné zdroje pomalého výkonu pre aplikácie plátna
Bežné problémy a riešenia pre službu Power Apps
Riešenie problémov pri spúšťaní pre Power Apps