Běžné problémy a řešení týkající se výkonnosti aplikací plátna

Článek
03/15/2023

Můžete vytvářet aplikace plátna použitím široké řady různých zdrojů dat. Vyberte správný zdroj dat a konektor v závislosti na obchodních potřebách a scénářích, pro které aplikaci navrhujete. Pro podnikové aplikace je doporučený zdroj dat Microsoft Dataverse, protože poskytuje několik výhod ohledně výkonu. U aplikací s několika transakcemi můžete použít jakékoli jiné dostupné zdroje dat ve vašem prostředí.

Pokud jde o výkon aplikace, zamyslete se nad počtem uživatelů, kteří budou aplikaci používat, až bude publikována; objem transakcí vytvoření, načtení, aktualizací a odstranění (CRUD); typ datových interakcí; geografický přístup; druhy zařízení, která uživatelé používají.

V tomto článku se dozvíte o některých nejčastějších problémech s výkonem, kvůli nimž mohou aplikace plátna běžet pomalu, a jak je vyřešit. Tyto informace vám pomohou zlepšit výkon aplikace s ohledem na váš obchodní plán a růst.

Začneme některými běžnými problémy s výkonem a řešeními, ke kterým dochází bez ohledu na použitý konektor. V pozdějších částech si konkrétněji povíme o problémech s výkonem a řešeních pro různé konektory.

Než začnete, ujistěte se, že jste pochopili fáze provádění aplikací plátna a toky datových volání. Mimo to si přečtěte běžné příčiny pomalého výkonu aplikací plátna, které obsahují běžná úskalí, kterým se můžete vyhnout při navrhování nebo aktualizaci aplikací plátna.

Velké datové sady se načítají pomalu na různých platformách

Výkon aplikace se může lišit při načítání velkých sad dat na různých platformách, jako je iOS nebo Android. K této variantě dochází z důvodu různých omezení síťových požadavků na každé platformě. Například počet povolených souběžných síťových požadavků se může u různých platforem lišit. Tento rozdíl může mít zásadní dopad na dobu načítání dat u velkých datových sad.

Doporučujeme načíst pouze data, která potřebujete okamžitě zobrazit na obrazovce. Ostatní data stránkujte a ukládejte do mezipaměti. Více informací: Tipy a osvědčené postupy ke zlepšení výkonu aplikace plátna

Načteno příliš mnoho sloupců

Doporučujeme vybrat pouze sloupce nezbytné pro aplikaci. Přidáním dalších (nebo všech) sloupců ze zdroje dat stáhnete všechna data ve sloupcích. Výsledkem této akce je vysoký počet režijních hovorů v síti, a tedy vysoké využití paměti v klientském zařízení. Tento problém může ještě více ovlivnit uživatele s mobilními zařízeními, pokud je omezena šířka pásma sítě, nebo pokud má zařízení omezenou paměť nebo starší procesor.

Pokud například pro svou aplikaci používáte jako zdroj dat Dataverse, ujistěte se, že jste povolili funkci explicitní výběr sloupců. Tato funkce umožňuje Power Apps omezit načítání dat pouze pro sloupce použité v aplikaci.

Chcete-li zapnout funkci explicitního výběru sloupců v aplikaci plátna, přejděte na Nastavení > Připravované funkce > Preview a poté zapněte přepínač Explicitní výběr sloupců.

Nepodporované nebo starší prohlížeče

Uživatelé, kteří používají nepodporované nebo starší prohlížeče, mohou mít problémy s výkonem. Zajistěte, aby uživatelé používali pouze podporované prohlížeče pro spouštění aplikací plátna.

Pomalý výkon kvůli geografické vzdálenosti

Výkon může ovlivnit zeměpisné umístění prostředí a vzdálenost zdroje dat ke koncovým uživatelům.

Doporučujeme, aby vaše prostředí bylo umístěno v blízkosti uživatelů. Ačkoli Power Apps používá pro obsah síť pro doručování obsahu (CDN) Azure, datová volání stále získávají data ze zdroje dat. Zdroj dat umístěný v jiné zeměpisné poloze může nepříznivě ovlivnit výkon aplikace.

Nadměrná zeměpisná vzdálenost ovlivňuje výkon různými způsoby, jako je latence, snížená propustnost, nižší šířka pásma a ztráta paketů.

Seznam povolených není konfigurován

Ujistěte se, že požadované adresy URL služby nebyly zablokovány nebo že byly přidány do seznamu povolených vaší brány firewall. Úplný seznam všech adres URL služeb, které je třeba povolit pro Power Apps, najdete v části Požadované služby.

Použití nedelegovatelných funkcí a omezení nevhodných řádků dat pro nedelegovatelné dotazy

Delegovatelné funkce delegují zpracování dat na zdroj dat a minimalizují režii na straně klienta. Když delegování není možné, můžete omezit limit řádků dat pro nedelegovatelné dotazy, aby počet řádků vrácených ze serverového připojení zůstal optimální.

Použití nedelegovatelných funkcí a nepatřičný limit řádku dat pro nedelegovatelné dotazy přidávají režii navíc při přenosu dat. Tato režie má za následek manipulaci s přijatými daty v haldě JS na straně klienta. Zajistěte použití delegovatelných funkcí pro aplikaci, kdykoli jsou k dispozici, a použití optimálního limitu řádku dat pro nedelegovatelné dotazy.

Další informace: Použití delegování, Přehled delegování

Událost OnStart vyžaduje vyladění

Událost OnStart se spustí při načítání aplikace. Volání velkého množství dat pomocí funkcí ve vlastnosti OnStart aplikace způsobí její pomalé načítání. Obrazovka s mnoha závislostmi ovládacích prvků a hodnot definovaných na jiné obrazovce bude ovlivněna pomalou navigací po obrazovce.

Následující části popisují některé z nejčastějších problémů, se kterými se v těchto situacích setkáváme.

Vysoký počet hovorů v události OnStart způsobuje pomalý start aplikace

V podniku může objem datových volání na centrální zdroj dat způsobit kritický bod serveru nebo spory o prostředky.

Použijte mechanismus mezipaměti k optimalizaci datových volání. Jedna aplikace může být používána mnoha uživateli, což má za následek mnoho datových volání na uživatele, které se dostanou na koncové body serveru. Tato datová volání mohou být místem, kde může dojít ke kritickým bodům či omezování.

Latence při události OnStart kvůli složitým skriptům

Složité skripty při události OnStart jsou jednou z nejčastějších chyb při navrhování aplikací plátna. Měli byste načíst pouze data potřebná pro spuštění aplikace.

Optimalizujte vzorec v události OnStart. Například můžete přesunout některé funkce do vlastnosti OnVisible. Tímto způsobem můžete nechat aplikaci rychle spustit a během jejího spouštění mohou pokračovat další kroky.

Více informací: Optimalizace vlastnosti OnStart

Tip

Doporučujeme použít vlastnost App.StartScreen, protože zjednodušuje spouštění aplikace a zvyšuje výkon aplikace.

Přetížení paměti na straně klienta

Kontrola spotřeby paměti aplikací plátna je důležitá, protože aplikace běží většinou na mobilních zařízeních. Výjimky paměti v haldě jsou nejpravděpodobnější příčinou spadnutí nebo zmrznutí (zablokování) aplikace plátna na určitých zařízeních.

Halda JavaScriptu (JS) může dosáhnout stropu kvůli složitým skriptům spuštěným na straně klienta pro přidávání, spojování, filtrování, řazení nebo seskupování sloupců. Ve většině případů může výjimka z nedostatku paměti pro haldu v klientovi způsobit zhroucení nebo zablokování aplikace.

Při použití dat ze zdrojů, jako jsou Dataverse nebo SQL Server, můžete použít objekt Zobrazení, který zajistí připojení, filtrování, seskupování nebo třídění na straně serveru místo na straně klienta. Tento přístup snižuje režii klienta při skriptování takových akcí.

Pokud se operace náročné na klienta, jako JOIN nebo Group By, provádí na straně klienta s datovou sadou s 2000 nebo více záznamy, počet objektů v haldě se zvýší, což povede k limitů paměti.

Vývojářské nástroje pro většinu prohlížečů umožňují profilovat paměť. Pomáhá to vizualizovat velikost haldy, dokumenty, uzly a naslouchací procesy. Profilujte výkon aplikace pomocí prohlížeče, jak je popsáno v přehledu vývojářských nástrojů Microsoft Edge (Chromium). Zkontrolujte scénáře, které překračují prahovou hodnotu paměti haldy JS. Více informací: Oprava problémů s pamětí

Příklad přetížené paměti pro aplikaci, jak je vidět z vývojářských nástrojů prohlížeče.

Důležité informace o výkonu pro konektor SQL Serveru

Konektor SQL Serveru pro Power Apps můžete použít pro připojení k místnímu SQL Serveru nebo Azure SQL Database. Tato část popisuje běžné problémy a řešení související s výkonem pro použití tohoto konektoru pro aplikaci plátna. Více informací: Připojení k serveru SQL Server z Power Apps, Vytvoření aplikace plátna z Azure SQL Database

Poznámka

Ačkoli se tato část zabývá konektorem SQL Serveru a jeho problémy s výkonem a příslušnými řešeními, většina doporučení platí také při použití libovolného typu databáze jako zdroje dat, například MySQL nebo PostgreSQL.

Pojďme se podívat na běžné problémy s výkonem a jejich řešení při použití konektoru SQL Serveru pro aplikace plátna.

Dotaz N+1

Galerie generující příliš mnoho požadavků na servery způsobily problém s dotazem N+1. Problém s dotazem N+1 je jedním z nejčastěji se vyskytujících problémů při používání ovládacího prvku Galerie.

Chcete-li se problému vyhnout, použijte prohlížet objekty v back-endu SQL nebo změňte scénáře uživatelského rozhraní.

Skenování tabulky místo hledání indexu

Aplikace může zpomalit, pokud funkce používané aplikací spouští dotazy v databázi, což má za následek skenování tabulek místo hledání indexu. Další informace: Rady, skenování tabulky a hledání indexu

Chcete-li tyto problémy vyřešit, ve vzorci použijte StartsWith namísto IN. Při použití zdroje dat SQL skončí operátor StartsWith v hledání indexu, ale operátor IN skončí ve skenování indexu nebo tabulky.

Pomalé dotazy

Můžete profilovat a ladit pomalé dotazy a indexy v databázi SQL. Pokud například v určitém sloupci existuje vzorec, který získává určitá data v sestupném pořadí (DESC), měl by tento sloupec řazení obsahovat index s klesajícím pořadím. Indexový klíč standardně vytváří vzestupné pořadí (ASC).

Můžete také zkontrolovat adresu URL požadavků na data. Například následující fragment požadavku na data (částečné volání OData) požádá SQL o vrácení 500 záznamů odpovídajících sloupci Hodnota a seřazení podle ID v sestupném pořadí.

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

Tento příklad pomáhá pochopit požadavky na index pro naplnění takových podmínek požadavku. Pokud v tomto příkladu má sloupec ID index v sestupném pořadí, bude dotaz proveden rychleji.

Zkontrolujte plán spuštění pomalých dotazů a zjistěte, zda existuje skenování tabulky nebo indexu. Sledujte jakékoli nadměrné náklady na vyhledávání klíčů v plánu spuštění.

Další informace:

Spor o prostředky databáze

Zajistěte, že zdroj dat – databáze SQL – neobsahuje žádné spory o prostředky, jako jsou omezení výkonu procesoru, spory I/O, přetížení paměti nebo spor tempDB. Zkontrolujte také, zda nedošlo k prodlevě uzamčení, čekání, zablokování a dotazu.

Tip

Pomocí automatického ladění získáte přehled o potenciálních problémech s výkonem dotazů, doporučených řešeních a automatickém řešení zjištěných problémů.

Těžkopádný klient nebo nadměrné požadavky

Aplikace spouštějící operace Group By, Filter By nebo JOIN na straně klienta používá prostředky procesoru a paměti z klientských zařízení. V závislosti na velikosti dat mohou tyto operace zahrnovat delší skriptování na straně klienta, což zvyšuje velikost haldy JS na straně klienta. Při použití místního zdroje dat se tento problém zvyšuje, protože každé datové volání vyhledávání putuje do zdroje dat přes datovou bránu.

V takových situacích použijte objekt Zobrazení v databázi SQL pro operace Group By, Filter By nebo JOIN. Zobrazení mohou používat selektivní sloupce a odebrat nepotřebné sloupce s velkými datovými typy, jako jsou NVARCHAR(MAX), VARCHAR(MAX) a VARBINARY(MAX).

Tip

Tento přístup také pomáhá řešit problém s dotazem N+1.

Velikost dat přenesených do klienta

Ve výchozím nastavení zobrazuje aplikace plátna data pomocí tabulek nebo zobrazení z dostupných databázových objektů. Načtení všech sloupců z tabulky může mít za následek pomalou odezvu, zejména při použití velkých datových typů, jako je NVARCHAR(MAX).

Přenos velkého množství dat klientům nějakou dobu trvá. Tento přenos má také za následek více času skriptování, když existuje velké množství dat v haldě JS na straně klienta, jak je popsáno dříve v tomto článku.

Chcete-li zmenšit velikost dat přenášených na klienta, použijte zobrazení se specifickými sloupci požadovanými pro aplikaci a zajistěte, aby byl povolen explicitní výběr sloupců, jak je popsáno dříve v tomto článku.

Důležité informace o místním SQL Serveru

Výkon aplikací plátna pomocí konektoru SQL Serveru s místní datovou bránou může být ovlivněn různými způsoby. V této části jsou uvedeny běžné problémy s výkonem a řešení specifická pro použití místního zdroje databáze.

Poškozená místní brána dat

Organizace mohou definovat více uzlů pro místní brány dat. I když je jeden z uzlů nedosažitelný, žádosti o data z poškozeného uzlu nevrátí výsledek v rozumném čase, nebo způsobí chybové zprávy „nedosažitelný“ po chvíli čekání.

Zajistěte, aby všechny uzly místní brány dat byly v pořádku a nakonfigurovány s minimální latencí sítě mezi uzly a instancí SQL.

Umístění místní brány dat

Brána dat vyžaduje k interpretaci požadavků OData síťová volání do místních zdrojů dat. Například datová brána musí chápat schéma datové tabulky, aby mohla přeložit požadavky OData na příkazy Data Manipulation Language (DML) jazyka SQL. Režie navíc vznikne, když je brána dat nakonfigurována v samostatném umístění s vysokou latencí sítě mezi bránou dat a instancí SQL.

V podnikovém prostředí se doporučuje mít škálovatelný cluster brány dat, když se očekávají náročné požadavky na data. Zkontrolujte, kolik připojení je navázáno mezi uzly brány dat a instancí SQL.

Kontrolou souběžných připojení v místní bráně dat nebo instanci SQL může vaše organizace rozhodnout, kdy je třeba bránu dat škálovat a s kolika uzly.

Škálovatelnost brány dat

Pokud očekáváte přístup k velkému objemu dat z místní brány dat, pro pokrytí tak velkého objemu požadavků může být překážkou pouze jeden uzel místní brány dat.

Jeden uzel místní brány dat může stačit k řešení 200 nebo méně souběžných připojení. Kromě toho, pokud všechna tato souběžná připojení aktivně provádějí dotazy, ostatní požadavky nakonec čekají na dostupné připojení.

Informace o tom, jak zajistit, aby se vaše místní datová brána škálovala podle objemu dat a požadavků, naleznete v tématu Monitorování a optimalizace výkonu místní brány dat.

Důležité informace o Azure SQL Database

Aplikace plátna se mohou připojit k Azure SQL Database pomocí konektoru SQL Serveru. Běžnou příčinou problémů s výkonem při používání Azure SQL Database je výběr nesprávné úrovně pro vaše obchodní požadavky.

Azure SQL Database je k dispozici v různých úrovních služby s různými funkcemi pro plnění různých obchodních požadavků. Další informace o vrstvách naleznete v dokumentaci k Azure SQL Database.

Při náročných požadavcích na data mohou být prostředky vybrané na dané úrovni zahlceny při dosažení prahové hodnoty. Takové zahlcení omezuje výkon další sady dotazů.

Zkontrolujte úroveň služby pro Azure SQL Database. Nižší vrstva by měla určitá omezení. Z hlediska výkonu jsou důležité CPU, propustnost IO a latence. Proto doporučujeme pravidelně kontrolovat výkon databáze SQL a kontrolovat, zda využití prostředků nepřekračuje prahovou hodnotu. Například místní SQL Server normálně nastavuje prahovou hodnotu využití CPU na přibližně 75 %.

Důležité informace o výkonu pro konektor SharePoint

Konektor SharePoint můžete použít k vytváření aplikací pomocí dat aplikace Seznamy Microsoft. Můžete také vytvářet aplikace plátna přímo ze zobrazení seznamu. Pojďme se podívat na běžné problémy s výkonem a jejich řešení při použití zdroje dat SharePoint s aplikacemi plátna.

Příliš mnoho sloupců dynamického vyhledávání

SharePoint podporuje různé datové typy, včetně dynamických vyhledávání, jako je Osoba, Skupina a Vypočítáno. Pokud seznam definuje příliš mnoho dynamických sloupců, manipulace s těmito dynamickými sloupci uvnitř aplikace SharePoint trvá déle před vrácením dat klientovi, na kterém je spuštěna aplikace plátna.

Vyhněte se nadměrnému používání sloupců dynamického vyhledávání v SharePoint. Toto nadužívání může mít za následek zbytečné a nadbytečné režijní náklady na straně SharePoint při manipulaci s daty. Místo toho můžete například použít statický sloupec k uchování e-mailových aliasů nebo jmen osob.

Sloupec s obrázky a příloha

Velikost obrázku a připojeného souboru může při načítání do klienta způsobit pomalou odezvu.

Zkontrolujte seznam a zajistěte, aby byly definovány pouze nezbytné sloupce. Počet sloupců v seznamu ovlivňuje výkon požadavků na data. To je způsobeno spárovanými záznamy, nebo jsou načteny záznamy až do stanovených limitů řádků dat a přeneseny zpět do klienta se všemi sloupci definovanými v seznamu, i když je aplikace všechny nepoužívá.

Povolte funkci explicitního výběru sloupců, jak je popsáno výše v tomto článku, abyste dotazovali pouze sloupce používané aplikací.

Velké seznamy

Pokud máte velký seznam se stovkami tisíc záznamů, zvažte rozdělení seznamu nebo rozdělte seznam do několika seznamů na základě parametrů, jako jsou kategorie nebo datum a čas.

Vaše data mohou být například ukládána do různých seznamů každý rok nebo měsíc. V takovém případě můžete aplikaci implementovat a umožnit uživateli vybrat časový interval pro načtení dat v tomto rozsahu.

V rámci kontrolovaného prostředí výkonnostní benchmark prokázal, že výkon požadavků OData oproti aplikaci Seznamy Microsoft nebo SharePoint výrazně souvisí s počtem sloupců v seznamu a počtem načítaných řádků (omezeno limitem datových řádků pro nedelegovatelné dotazy). Díky nižšímu počtu sloupců a nižšímu limitu řádků dat může aplikace plátna lépe fungovat.

V reálném světě jsou však aplikace navrženy tak, aby splňovaly určité obchodní požadavky. Snížení omezení řádku dat nebo počtu sloupců v seznamu nemusí být rychlé ani jednoduché. Doporučujeme však monitorovat požadavky OData na straně klienta a vyladit omezení řádku dat pro nedelegovatelné dotazy a počet sloupců v seznamu .

Důležité informace o výkonu při použití Dataverse jako zdroje dat

Když používáte Microsoft Dataverse jako zdroj dat, požadavky na data jdou přímo do instance prostředí, aniž by procházely skrze Azure API Management. Více informací: Tok datového volání při připojení k Microsoft Dataverse

Tip

Při použití vlastních tabulek v Dataverse může být vyžadována další konfigurace zabezpečení, aby uživatelé mohli prohlížet záznamy pomocí aplikací plátna. Další informace: Koncepce zabezpečení v Dataverse, Konfigurace zabezpečení uživatelů na prostředky v prostředí a Role zabezpečení a oprávnění

Aplikace plátna připojená k Dataverse může fungovat pomalu, pokud na straně klienta spouští náročné skriptování, například Filter By nebo JOIN, namísto na straně serveru.

Použijte zobrazení Dataverse, když to je možné. Zobrazení s požadovanými kritérii pro připojení nebo filtrování pomáhá snížit režii při používání celé tabulky. Například pokud potřebujete spojit tabulky a filtrovat jejich data, můžete definovat pohled spojením tabulek a výběrem pouze požadovaných sloupců. Poté použijte toto zobrazení ve vaší aplikaci, která vytvoří tuto režii na straně serveru pro připojení/filtrování místo na straně klienta. Tato metoda snižuje nejen dodatečné operace, ale také přenos dat. Informace o úpravě kritérií filtrování a řazení najdete v části Úprava kritérií filtru.

Důležité informace o výkonu pro konektor Excel

Konektor Excel poskytuje připojení z aplikace plátna k datům v tabulce uvnitř souboru aplikace Excel. Tento konektor má omezení ve srovnání s jinými zdroji dat, například omezenými delegovatelnými funkcemi, které omezují aplikaci plátna na načítání dat z tabulky pouze do výše 2000 záznamů. Chcete-li načíst více než 2000 záznamů, rozdělte data do různých datových tabulek jako jiné zdroje dat.

Pojďme se podívat na běžné problémy s výkonem a jejich řešení při použití aplikace Excel jako zdroje dat pro aplikace plátna, a jak je řešit.

Příliš mnoho datových tabulek a dat

Aplikace může být pomalá, když používá soubor aplikace Excel s příliš mnoha datovými tabulkami, které obsahují obsahují spoustu dat v několika sloupcích. Soubor Excel není relační databáze ani zdroj dat, který poskytuje delegovatelné funkce. Power Apps musí nejprve načíst data z definovaných datových tabulek a poté použít funkce jako Filter, Sort, JOIN, Group By a Search.

Příliš mnoho datových tabulek s mnoha řádky a sloupci ovlivňuje výkon aplikace a režii na straně klienta, protože s každou datovou tabulkou je třeba manipulovat v rámci haldy JS. Tento efekt také vede k tomu, že aplikace spotřebovává více paměti na straně klienta.

Abyste zajistili, že vaše aplikace nebude takovým chováním ovlivněna, musíte definovat v datové tabulce v souboru Excel pouze nezbytné sloupce.

Náročné transakce

Excel není relační databázový systém. Jakékoli změny v aplikaci spravuje Excel stejným způsobem jako uživatel, který mění data v souboru Excel. Pokud má aplikace vysoký počet čtení, ale méně operací CRUD (vytvoření/aktualizace/odstranění), může fungovat dobře. Pokud však aplikace provádí náročné transakce, může to nepříznivě ovlivnit výkon aplikace.

Neexistuje žádná specifická prahová hodnota pro počet transakcí, protože to závisí také na manipulovaných datech. Na výkon aplikace má vliv i několik dalších aspektů, například režie sítě nebo zařízení uživatele.

Pokud máte data jen pro čtení, můžete je místo toho načíst z aplikace zdroj dat a importovat je do aplikace místně. U podnikových aplikací použijte místo toho zdroje dat typu Dataverse, SQL Server nebo SharePoint.

Velikost souboru

Můžete si vybrat ze široké nabídky cloudových úložišť s různorodou nebo konfigurovatelnou úložnou kapacitou pro soubor Excel. Jeden velký soubor aplikace Excel se všemi tabulkami definovanými v jednom souboru však přidává další režii pro aplikaci při stahování souboru a čtení dat při načítání na straně klienta.

Místo použití jednoho velkého souboru rozdělte data do více souborů Excel s minimálními datovými tabulkami. Poté se ke každému souboru připojte, pouze když to potřebujete. Tímto způsobem se načítání dat z datové tabulky děje ve fragmentech, což snižuje režii mnoha tabulek nebo velké datové sady.

Umístění souboru

Geografické umístění zdroje dat a vzdálenost k umístění klienta může představovat klasický kritický bod výkonu aplikace a způsobit latenci sítě. Tento efekt může zesílit u mobilního klienta s omezenou šířkou pásma pro připojení.

Je lepší mít soubor poblíž koncových uživatelů (nebo většiny koncových uživatelů v případě globální cílové skupiny), aby bylo možné soubor rychle stáhnout.

Další kroky

Tipy a osvědčené postupy ke zlepšení výkonu aplikací plátna

Viz také

Principy fází provádění aplikací plátna a tok volání dat
Běžné zdroje pomalého výkonu pro aplikaci plátna
Běžné problémy a řešení v Power Apps
Řešení problémů se spouštěním v Power Apps