Vászonalapú alkalmazások gyakori teljesítményproblémái és megoldásaik

Vászonalapú alkalmazásokat különféle adatforrások sorának használatával hozhat létre. Válassza ki a megfelelő adatforrást és összekötőt az üzleti igényektől és forgatókönyvektől függően, amelyekhez az alkalmazást tervezi. Vállalati alkalmazások esetén a Microsoft Dataverse az ajánlott adatforrás, mivel számos teljesítménybeli előnyt biztosít. A kevés tranzakciót tartalmazó alkalmazások esetén a környezetében rendelkezésre álló más adatforrásokat is használhatja.

Az alkalmazások teljesítményével kapcsolatos szempontokat figyelembe vételekor gondolja át, hogy hány felhasználó fogja használni az alkalmazást a közzétételkor, a CRUD (létrehozás/lekérés/frissítés/törlés) tranzakciók mennyiségét, az adatkapcsolati tevékenységek típusát, a földrajzi hozzáférést és a felhasználók eszközeinek típusait.

Ebből a cikkből megismerheti a leggyakoribb teljesítményproblémákat, amelyek miatt a vászonalapú alkalmazások lassan futnak, és azok megoldásait. Ez az információ segít az üzleti tervet és a növekedést szem előtt tartva javítani az alkalmazás teljesítményét.

Kezdésként áttekintünk néhány gyakori teljesítményproblémát és azok megoldásait a felhasznált összekötőtől függetlenül. A későbbi szakaszokban a külömnböző összekötőkre jellemző teljesítményproblémákról és megoldásokról olvashat.

Mielőtt elkezdené, győződjön meg arról, hogy ismeri a vászonalapú alkalmazások végrehajtási fázisait és az adathívások folyamatát. A Vászonalapú alkalmazások lassú teljesítményének gyakori okai rész emellett bemutatja a gyakori buktatókat, amelyeket elkerülhet a vászonalapú alkalmazások tervezése és frissítése során.

Nagy adathalmazok betöltése lassú különböző platformokon

Az alkalmazások teljesítménye eltérő lehet, ha nagy adatkészleteket tölt be különböző platformokon, például iOS vagy Android. Ez a változás az egyes platformokon a hálózati kérelmekre vonatkozó eltérő korlátozások miatt fordul elő. Az egyidejű hálózati kérelmek száma platformok szerint eltérő lehet például. Ez a különbség jelentős hatással lehet a nagy adathalmazok adatbetöltési idejére.

Javasoljuk, hogy csak az adatokat töltse be, amelyeket azonnal meg kell jeleníteni a képernyőn. Egyéb adatoknál bontsa oldalakra és gyorsítótárazza az adatokat. További információk: Tippek és gyakorlati tanácsok a vászonalapú alkalmazás teljesítményének javítására

Túl sok lekért oszlop

Javasoljuk, hogy csak az alkalmazáshoz szükséges oszlopokat válassza ki. Ha több vagy az összes oszlopot hozzáadja az adatforrásról, az letölti az összes oszlopadatot. Ennek a műveletnek az eredménye a hálózati hívások nagy száma, és így az ügyféleszközön nagy memóriahasználat. Ez a probléma a mobilkészülékekkel rendelkező felhasználókat még jobban érintheti, ha korlátozott a hálózati sávszélesség, vagy ha egy eszköz korlátozott memóriával vagy korábbi processzorral rendelkezik.

Ha például az alkalmazáshoz Dataverse adatforrást használ, ellenőrizze, hogy engedélyezte-e a Kifejezett oszlopkijelölés funkciót. Ez a funkció csak az alkalmazásban használt oszlopok adatlekérésének korlátozását teszi lehetővé a Power Apps számára.

Az explicit oszlopkiválasztás funkciónak a vászonalapú alkalmazásban történő bekapcsolásához menjen a Beállítások > Hamarosan megjelenő funkciók > Előzetes verzió fülekre, majd kapcsolja be az Explicit oszlopkiválasztás váltógombot.

Nem támogatott vagy korábbi böngészők

A nem támogatott vagy korábbi böngészőt használó felhasználók teljesítménybeli problémákat tapasztalhatnak. Győződjön meg róla, hogy a felhasználók csak a támogatott böngészőket használják vászonalapú alkalmazások futtatásához.

Lassú teljesítmény a földrajzi távolság miatt

A környezet földrajzi elhelyezkedése, valamint az adatforrás felhasználóktól való távolsága hatással van a teljesítményre.

Javasoljuk, hogy a környezet a felhasználókhoz közel legyen. Bár a Power Apps az Azure tartalomkézbesítési hálózatot használja a tartalomhoz, az adathívások továbbra is az adatforrástól kérik le az adatokat. A más földrajzi helyszínen található adatforrás negatív hatással lehet az alkalmazás teljesítményére.

A nagy földrajzi távolság különböző formában befolyásolják a teljesítményt, például késés, kisebb adatátviteli sebességet, alacsonyabb sávszélesség és csomagvesztés formájában.

Engedélyezési lista nincs konfigurálva

Ügyeljen arra, hogy a szükséges szolgáltatások URL-címei ne legyenek letiltva, vagy vegye fel őket a tűzfal engedélyezési listájára. A Power Apps számára engedélyezni szükséges URL-címek teljes listájáért látogasson el a következőhöz: Szükséges szolgáltatások.

Nem delegálható funkciók használata, és nem megfelelő adatsorkorlátok a nem delegálható lekérdezések esetében

A delegálható funkciók delegálják az adatok feldolgozását az adatforráshoz, minimálisra csökkentve a munkaterhelést az ügyfél oldalán. Ha a delegálás nem lehetséges, korlátozhatja a nem delegálható lekérdezések adatsorkorlátját, hogy a kiszolgálóalapú kapcsolatról visszaadott sorok száma továbbra is optimális maradjon.

A nem delegálható funkciók használata és a nem megfelelő adatsor-korlátozások a nem delegálható lekérdezések esetében további munkaterhelést jelent az adatátvitel során. Ez a többletterhelés a kapott adatok JS halommemóriába való áthelyezését eredményezi az ügyféloldalon. Gondoskodjon róla, hogy amikor csak lehet, delegálható funkciókat használjon az alkalmazáshoz, és használja az optimális adatsorkorlátot a nem delegálható lekérdezések esetében.

További információk: Delegáció használata, Delegáció áttekintése

Az OnStart-eseményhez hangolás szükséges

Az OnStart-esemény az alkalmazás betöltésekor fut. Ha nagy adatmennyiséget hív meg az alkalmazás OnStart tulajdonságának függvényei segítségével, akkor az alkalmazás lassan töltődik be. A másik képernyőn megadott vezérlőelemek és értékek tekintetében erős függőséggel rendelkező képernyőn lassabb lesz a navigáció.

A következő szakaszok az ezekben a helyzetekben tapasztalt leggyakoribb problémákat ismertetik.

Nagy számú hívás az OnStart-eseményben, ami miatt az alkalmazás lassan indul

Nagyvállalati környezetben a központi adatforrásba irányuló adathívások nagy mennyisége a kiszolgálón szűk keresztmetszetet vagy erőforrásokért folytatott versenyt eredményez.

A gyorsítótárazási mechanizmus használata az adathívások optimalizálására. Egy alkalmazást sok felhasználó is használhat, ami a kiszolgáló végpontjait elérő több felhasználónkénti adathívást eredményez. Ezek az adathívások olyan helyet eredményezhetnek, ahol szűk keresztmetszet vagy leszabályozás alakulhat ki.

Komplex parancsfájlok miatti késés az OnStart-események esetében

Az OnStart-eseményeknél a komplex parancsfájlok jelentik a vászonalapú alkalmazások tervezése során elkövethető leggyakoribb hibát. Csak az alkalmazás indításához szükséges adatokat kell megkapniuk.

Optimalizálja a képletet egy OnStart-eseményben. Például helyezzen át néhány funkciót inkább az OnVisible tulajdonságba. Így gyorsan elindíthatja az alkalmazást, és az alkalmazás indítása közben más lépések is folytatódhatnak.

További információk: Az OnStart tulajdonság optimalizálása

Tipp.

Javasoljuk, hogy használja az App.StartScreen tulajdonságot, mivel egyszerűbbé teszi az alkalmazás indítását, és növeli az alkalmazás teljesítményét.

Memórianyomás az ügyféloldalon

A vászonalapú alkalmazások memóriafogyasztásának ellenőrzése fontossá válik, mivel a legtöbb esetben az alkalmazás mobileszközökön fut. A halommemóriában előforduló memóriakivételek jelentik a legvalószínűbb okokat egy egyes eszközökön összeomló vagy lefagyó vászonalapú alkalmazás esetében.

A JavaScript (JS) halommemória elérheti a korlátot az oszlopok hozzáadására, összevonására, szűrésére, rendezésére vagy csoportosítására használt, ügyféloldalon futó komplex parancsfájlok miatt. A legtöbb esetben az elfogyott memória miatti kivétel az ügyfél halommemóriájában az alkalmazás összeomlását vagy fagyását idézheti elő.

Ha olyan forrásból származó adatokat használ, mint például a Dataverse vagy az SQL Server, a Nézet objektumot használhatja annak biztosítására, hogy az összevonás, a szűrés, a csoportosítás vagy a rendezés a kiszolgálóoldalon, és nem az ügyféloldalon történik. Ez a megközelítés csökkenti a parancsfájlokkal kapcsolatos ügyfélterhelést az ilyen műveletek esetében.

Ha az 2000 vagy több rekordot tartalmazó adathalmazzal rendelkező ügyféloldalon nagy ügyfélterheléssel rendelkező műveletek – például JOIN vagy a Group By – történnek, a halommemóriában található objektumok száma nő, és túllépi a memóriakorlátokat.

A legtöbb böngészőhöz rendelkezésre álló fejlesztői eszközök lehetővé teszik a memória profilozását. Vizuálisan ábrázolható a segítségével a halommemória mérete, a dokumentumok, a csomópontok és a figyelők. Az alkalmazás teljesítménye profilozható böngésző segítségével a Microsoft Edge (Chromium) Fejlesztői eszközök áttekintése részben leírt módon. Ellenőrizze a JS halommemória küszöbértékét túllépő alkalmazási helyzeteket. További információk: Memóriaproblémák kijavítása

Teljesítménnyel kapcsolatos megfontolások az SQL Server Connector esetén

A Power Apps SQL Server Connector-összekötője használatával csatlakozhat az SQL Server helyszíni változatához vagy az Azure SQL Database adatbázishoz. Ez a szakasz a teljesítménnyel kapcsolatos általános problémákat és megoldásokat ismerteti az összekötő vászonalapú alkalmazással való használatával kapcsolatban. További információk: Csatlakozás az SQL Serverhez a Power Apps szolgáltatásból, Vásznonalapú alkalmazás létrehozása az Azure SQL Database-ból

Megjegyzés

Bár ez a szakasz az SQL Server Connector összekötőkre hivatkozik a teljesítményproblémákkal és megoldásokkal kapcsolatban, az ajánlások nagy része bármely adatforrásként használt adatbázistípusra érvényes — mint például —, a MySQL vagy a PostgreSQL.

Nézzük meg a gyakori teljesítményproblémákat és megoldásokat, amikor az SQL Server Connector összekötők vannak használatban a vászonalapú alkalmazásokhoz.

N+1 lekérdezés

A kiszolgálóknak túl sok lekérdezést generáló katalógusok N+1 lekérdezési problémát okoztak. Az N+1 lekérdezési probléma az egyik leggyakrabban tapasztalt probléma a Katalógus vezérlő használata esetén.

A probléma elkerülése érdekében használja az SQL háttér-objektumaiból a nézetobjektumokat, vagy módosítsa a felhasználói felület használati forgatókönyvét.

Indexkeresés helyett táblapásztázás

Az alkalmazás lelassulhat, ha az alkalmazás által használt funkciók lekérdezéseket futtatnak az adatbázisban, ami indexkeresés helyett táblapásztázást eredményez. További információk: Tippek, Táblapásztázás és Indexkeresés

Az ilyen problémák megoldásához használja a StartsWith elemet az IN helyett a képletben. SQL-adatforrással a StartsWith operátor egy indexkeresést eredményez, de az IN operátor egy index- vagy táblapásztázást eredményez.

Lassú lekérdezések

Profilozhatja és hangolhatja a lassú lekérdezéseket és indexeket az SQL-adatbázisban. Ha például egy képlet az adatokat csökkenő (DESC) sorrendben kap meg egy bizonyos oszlopban, akkor a rendezési oszlopnak csökkenő sorrendű indexszel kell rendelkeznie. Az indexkulcs alapértelmezés szerint növekvő (ASC) sorrendet hoz létre.

Az adatkérések URL-címét is ellenőrizheti. Például a következő adatkérési kódrészlet (részleges OData-hívás) felkéri az SQL-t, hogy adjon vissza 500 rekordot az oszlopot az Érték elemmel megfeleltetve, az Azonosító szerint csökkenő sorrendben rendezve.

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

Így könnyebben érthetők az ilyen kérelemfeltételekre vonatkozó indexkövetelmények. Ebben a példában ha az Azonosító oszlopnak csökkenő sorrendű indexszel rendelkezik, a lekérdezés gyorsabban végrehajtható.

Ellenőrizze a lassú lekérdezések végrehajtási tervét, hogy léteznek-e tábla- vagy indexpásztázások. Kövesse nyomon a Kulcskeresés túlzott költségeit a végrehajtási tervben.

További információ:

• Teljesítmény nyomon követése és hangolása
• A teljesítmény figyelése a Lekérdezéstár használatával
• Bővített események – áttekintés

Versengés az adatbázis-erőforrásokért

Ellenőrizze, hogy az adatforrás — SQL-adatbázis — esetében nincs versengés az erőforrásokért, például szűk keresztmetszet, I/O-versengés, memórianyomás vagy tempDB-versengés. Ellenőrizze a zárolásokat, a várakozásokat, a kettős zárolást és a lekérdezések időtúllépéseit.

Tipp.

Az automatikus hangolás segítségével betekintést kaphat az esetleges lekérdezési teljesítménnyel kapcsolatos problémákba és az ajánlott megoldásokba, és automatikusan kijavíthatja az azonosított problémákat.

Vastag ügyfél vagy túlzott mértékű kérelmek

Az ügyféloldalon Csoportosítási szempont, Szűrési szempont vagy JOIN műveleteket futtató alkalmazás processzort és memóriaerőforrásokat használ az ügyféleszközökről. Az adatmérettől függően ezek a műveletek az ügyféloldalon több parancsprogram-kezelési időt vehetnek igénybe, ami növeli a JS-halommemória méretét az ügyfélen. Helyszíni adatforrás használatakor ez a probléma növekszik, mivel minden keresési adathívás az adatforráshoz az adatátjárón keresztül történik.

Ilyen helyzetekben használja a View objektumot az SQL Database-ben a Group by , Filter By vagy JOIN műveletekhez. A nézetek szelektív oszlopokat használhatnak, és eltávolítják a nem szükséges big data típusú oszlopokat, mint például a NVARCHAR(MAX), VARCHAR(MAX), és VARBINARY(MAX).

Tipp.

Ez a megközelítés segít az N+1 lekérdezési probléma megoldásában is.

Az ügyfélnek átvitt adatok mérete

A vászonalapú alkalmazások alapértelmezés szerint a rendelkezésre álló adatbázis-objektumokból származó táblák vagy nézetek segítségével jelenítik meg az adatokat. A tábla minden oszlopának beolvasása lassú válaszhoz vezethet, különösen big data típusok, például NVARCHAR(MAX) használata esetén.

A nagy mennyiségű adat ügyfélnek történő átadása sok időt veszi igénybe. Az átvitel több parancsfájlidőt eredményez, amikor nagy mennyiségű adat található az ügyféloldali JS-memóriahalomban, ahogy azt leírtuk korábban ebben a cikkben.

Az ügyfélnek átvihető adatok méretének csökkentése érdekében használjon az alkalmazáshoz szükséges konkrét oszlopokat tartalmazó nézeteket, és gondoskodjon róla, hogy a cikkben leírtaknak megfelelően a kifejezett oszlopkijelölés legyen engedélyezve.

Az SQL Server helyszíni változatára vonatkozó megfontolások

A helyszíni adatátjáróval rendelkező SQL Server Connector összekötőt használó vászonalapú alkalmazások teljesítményét több tényező befolyásolhatja. Ez a szakasz a leggyakoribb teljesítményproblémákat és megoldásaikat sorolja fel a helyszíni adatbázisforrás használata esetén.

Nem kifogástalan helyszíni adatátjáró

A szervezetek több csomópontot is meghatároznak az helyszíni adatátjáró számára. Még ha az egyik csomópont nem is érhető el, a nem kifogástalan csomópontra küldött adatkérések nem küldik vissza az eredményt egy megfelelő időkereten belül, vagy egy bizonyos várakozási idő után a „nem elérhető” hibaüzenet jelenik meg.

Ellenőrizze, helyszíni összes helyszíni adatátjáró csomópontja kifogástalan-e, és konfigurálja úgy, hogy a csomópontok és az SQL-példány között minimális hálózati késés legyen.

A helyszíni adatátjáró helye

Az adatátjárónak az OData-kérések értelmezéséhez hálózati hívásokra van szüksége a helyszíni adatforrásokhoz. Az adatkapunak például meg kell értenie az adattábla sémáját, hogy az OData-kérelmeket SQL adatmanipulációs nyelv (DML) utasításokká fordítsa. További többletterhelés akkor adódik hozzá, ha az adatátjáró külön helyen van konfigurálva, ahol nagy a hálózati késés az adatátjáró és az SQL-példány között.

Nagyvállalati környezetben javasolt méretezhető adatátjáró-fürt használata, ha nagy adatkérések várhatók. Ellenőrizze, hogy hány kapcsolat kerül létrehozásra az adatátjáró-csomópontok és az SQL-példány között.

A helyszíni adatátjárón vagy SQL-példányon lévő konkurens kapcsolatok ellenőrzésével a szervezet meghatározhatja, hogy az adatátjárót mikor kell kiterjeszteni, és hogy hány csomópontra van szükség.

Adatátjáró skálázhatósága

Ha nagy mennyiségű adat elérésére számít a helyszíni adatátjáróból, az helyszíni adatátjáró egyetlen csomóponttal szűk keresztmetszetté válhat nagy mennyiségű kérés kezelésekor.

Az helyszíni adatátjáró egyetlen csomópontja elegendő lehet 200 vagy annál kevesebb konkurens kapcsolat kezelésére. Azonban, ha mindezek a konkurens kapcsolatok aktív lekérdezéseket hajtanak végre, más kérések várnak ennek következtében egy rendelkezésre álló kapcsolatra.

További információkért azzal kapcsolatban, hogyan biztosítható, hogy a helyszíni adatátjáró méretezése az adatok és kérések mennyiségének megfelelően történik, lépjen a Helyszíni adatátjáró teljesítményének figyelése és optimalizálása.

Az Azure SQL Database adatbázissal kapcsolatos szempontok

A vászonalapú alkalmazások az SQL Server Connector összekötő használatával tudnak kapcsolódni az Azure SQL Database adatbázishoz. Az Azure SQL Database használata esetén a teljesítményproblémák gyakori oka, ha nem a megfelelő szintet választja ki az üzleti követelményeinek.

Az Azure SQL Database különböző szolgáltatási szinteken érhető el, különböző üzleti igényeknek megfelelő szolgáltatásokkal. A szintekkel kapcsolatos további információkért keresse fel a következőt: Azure SQL Database dokumentációja.

A nagy adatkérések esetén a kiválasztott szint erőforrásai leszabályozásra kerülhetnek a küszöbérték elérése után. Az ilyen leszabályozás veszélyezteti a lekérdezések következő halmazának teljesítményét.

Ellenőrizze az Azure SQL Database szolgáltatási szintjét. Az alsóbb szintnek vannak bizonyos korlátozásai és megkötései. Teljesítmény szempontjából fontos a processzor, az I/O-kapacitás és a késés. Ezért javasoljuk, hogy időnként ellenőrizze az SQL-adatbázis teljesítményét, és ellenőrizze, hogy az erőforrás-használat túllépi-e a küszöbértéket. Például a helyszíni SQL Server rendszerint 75%-ra állítja be a processzorhasználat küszöbértékét.

Teljesítménnyel kapcsolatos megfontolások a SharePoint-összekötő esetén

A SharePoint-összekötő segítségével alkalmazások hozhatók létre a Microsoft-listák adataival. Közvetlenül a listanézetből is létrehozhat vászonalapú alkalmazásokat. Nézzük meg a gyakori teljesítményproblémákat és megoldásokat, amikor egy SharePoint-adatforrás van használatban a vászonalapú alkalmazásokhoz.

Túl sok dinamikus keresési oszlop

A SharePoint különféle adattípusokat támogat, köztük a dinamikus kereséseket is, mint például a Személy, a Csoport és a Számított. Ha egy lista túl sok dinamikus oszlopot határoz meg, több időt vesz igénybe ezeknek a dinamikus oszlopoknak a módosítása a SharePointban, mielőtt adatokat ad vissza a vászonalapú alkalmazást futtató ügyfélnek.

Ne használja túl a dinamikus keresési oszlopokat a SharePointban. A túlhasználás elkerülhető és szükségtelen adatkezelési többletterhelést okozhat a SharePoint oldalán. Ehelyett a statikus oszlopok segítségével tárolhatja például az e-mail-aliasokat, illetve a személyek nevét.

Képoszlop és melléklet

A kép és a csatolt fájl mérete az ügyfélre való beolvasáskor lassú választ eredményezhet.

Ellenőrizze a listát, és győződjön meg arról, hogy csak a szükséges oszlopok vannak definiálva. A listában található oszlopok száma hatással van az adatkérések teljesítményére. Ez az egyeztetett rekordok vagy a megadott adatsorkorlátig beolvasott, és az ügyfélhez visszaküldött, a listában megadott összes oszloppal rendelkező rekordok miatt van — akár mindet felhasználja az alkalmazás, akár nem.

Ha a lekérdezést csak az alkalmazás által használt oszlopoknak szeretné elküldeni, engedélyezze a kifejezett oszlopkijelölés funkciót a jelen cikkben korábban leírt módon.

Nagy listák

Ha egy nagy, több százezer bejegyzésből álló listával rendelkezik, érdemes particionálni a listát, vagy több listára felosztani paraméterek (például kategóriák, dátum és idő) alapján.

Az adatok például évről évre vagy havi szinten különböző listákon tárolhatók. Ilyen esetben megtervezheti úgy az alkalmazást, hogy a felhasználó kiválaszthat egy időablakot, hogy beolvassa az adott tartományon belüli adatokat.

Szabályozott környezeten belül a teljesítménymutató igazolta, hogy a Microsoft-listákra vagy SharePointra irányuló OData-kérések teljesítménye nagy mértékben összefügg a lista oszlopainak számával és a lekért sorok számával (a nem delegálható lekérdezések adatsorkorlátja korlátozza). A kevesebb oszlop a és az alacsonyabb adatsorkorlát beállítása jobb teljesítményt tesz lehetővé a vászonalapú alkalmazás számára.

A valós világban azonban az alkalmazások úgy vannak kialakítva, hogy megfelelnek bizonyos üzleti követelményeknek. Lehet, hogy nem lehet gyorsan vagy egyszerűen csökkenteni az adatsorok korlátját vagy a listában található oszlopok számát. Ugyanakkor ajánlott az OData-kérelmek figyelése az ügyféloldalon, valamint a nem delegálható lekérdezések adatsorkorlátját és a -listában található oszlopok számának hangolása.

Teljesítménnyel kapcsolatos megfontolások, ha Dataverse van használatban adatforrásként

Ha adatforrásként Microsoft Dataverse-t használ, az adatkérések közvetlenül a környezeti példányhoz mennek, anélkül, hogy az Azure API-kezelésen keresztül haladnának. További információ: Adathívás áramlása a Microsoft Dataverse-hoz való csatlakozáskor

Tipp.

Ha egyéni táblákat használnak a Dataverse rendszerben, további biztonsági konfigurációkra lehet szükség ahhoz, hogy a felhasználók megtekinthessék a rekordokat a vászonalkalmazásokkal. További információk: Biztonsági fogalmak a Dataverse-ben, Felhasználói biztonság konfigurálása erőforrásokra egy környezetben, és Biztonsági szerepek és jogosultságok

A Dataverse-hez csatlakoztatott vászonalapú alkalmazás lassan végezheti el a feladatokat, ha nagy ügyféloldali parancsfájlokat (például Filter By vagy JOIN) futtat az ügyféloldalon a kiszolgáló oldala helyett.

Amikor csak lehet, használja a Dataverse nézeteit. A szükséges join vagy filter feltétellel rendelkező nézet segít csökkenteni a teljes tábla használatának többletterhelését. Ha például táblázatok összekapcsolására és adataik szűrésére van szükség, akkor a táblázatok összekapcsolásával meghatározhat egy nézetet, és csak a szükséges oszlopokat határozhatja meg. Ezután az alkalmazásból ezt a nézetet használja, amely ezt a többletterhelést a kiszolgálóoldalon hozza létre a join/filter művelet számára az ügyféloldal helyett.Ez a módszer nemcsak az extra műveleteket, hanem az adatátvitelt is csökkenti. A szűrési és rendezési feltételek szerkesztésével kapcsolatos további tudnivalókért lépjen a következőre: Szűrőfeltételek szerkesztése.

Teljesítménnyel kapcsolatos megfontolások az Excel-összekötő esetén

Az Excel-összekötő összekapcsolhatóságot biztosít egy vászonalapú alkalmazás és az Excel-fájl táblájában található adatok között. Ez az összekötő más adatforrásokkal összehasonlítva korlátozott funkciókkal rendelkezik — például korlátozott delegálható funkciókkal rendelkezik —, amely korlátozza a vászonalapú alkalmazás számára, hogy legfeljebb 2000 rekord erejéig töltsön be adatokat a táblázatból. 2000-nél több rekord betöltéséhez egyéb adatforrásként particionálja az adatokat a különböző adattáblákban.

Nézzük meg a gyakori teljesítményproblémákat és megoldásokat, amikor Excelt használ adatforrásként vászonalapú alkalmazásokhoz.

Túl sok adattábla és nagy adatméretet

Az alkalmazás teljesítménye lassú lehet, amikor túl sok adattáblát tartalmazó Excel-fájlt használ, vagy olyan adattáblákat, amelyek több oszlopban túl nagy mennyiségű adatot tartalmaznak. Az Excel-fájl nem relációs adatbázis, és nem adatforrás, amely delegálható függvényeket biztosít. A Power Apps-nak először adatokat kell betöltenie a meghatározott adattáblákból, majd ezután használhatja a függvényeket: Filter, Sort, JOIN, Group By és Search.

Túl sok olyan adattábla jelenléte, amely nagy számú sort és oszlopot tartalmaz, hatással van az alkalmazás teljesítményére és az ügyféloldali többletterhelésre, mivel minden adattáblát módosítani kell a JS-halommemórián belül. Ez a hatása azt is eredményezi, hogy az alkalmazás több ügyféloldali memóriát fogyaszt.

Annak érdekében, hogy az alkalmazást ne érintsék az ilyen problémák, csak a szükséges oszlopokat definiálja egy Excel-fájl adattábláján.

Nagy tranzakciók

Az Excel nem relációsadatbázis-rendszer. Az alkalmazáson végrehajtott módosításokat az Excel ugyanúgy kezeli, mint ahogyan a felhasználó az Excel-fájlokban módosítja az adatokat. Ha az alkalmazás nagy számú olvasással rendelkezik, de kevesebb CRUD-művelettel, akkor az is előfordulhat, hogy jól működik. Ha azonban az alkalmazás nagy tranzakciókat végez, az negatív hatással lehet az alkalmazás teljesítményére.

A tranzakciók száma esetén nincs konkrét küszöbérték, mivel az adatok kezelésének módjától is függ. Az alkalmazás teljesítményét számos más szempont is befolyásolja, ilyen például a hálózati többletterhelés vagy a felhasználó eszköze.

Ha csak olvasható adatokat használ, akkor az adatokat helyben importálhatja az alkalmazásba, ahelyett, hogy betöltené az adatforrásból. Nagyvállalati alkalmazások esetén használjon inkább olyan adatforrásokat, mint például a Dataverse, az SQL Server vagy a SharePoint.

Fájlméret

A felhőtárhelyek széles választéka közül választhat, amelyek eltérő — vagy konfigurálható — tárolókapacitással rendelkeznek az Excel-fájlhoz. Azonban egyetlen, minden táblát egy fájlban megadó nagy Excel-fájl további többletterhelést jelent az alkalmazás számára a fájl letöltésekor és az adatok ügyféloldali betöltésekor.

Egyetlen nagy fájl használata helyett ossza fel az adatokat több Excel-fájlra minimális adattáblák használatával. Ezután csak akkor kapcsolódhat mindegyik fájlhoz, amikor szükség van rá. Ily módon az adattáblákból az adatok részletekben kerülnek betöltésre, csökken a sok tábla vagy nagy adathalmazok miatti többletterhelés.

Fájl helye

Az adatforrás földrajzi helye, illetve az ügyfelek helyétől számított távolsága teljesítménybeli szűk keresztmetszetet okozhat az alkalmazás számára, és növelheti a hálózati késést. Ez a hatás tovább erősödhet korlátozott sávszélességgel rendelkező mobil ügyfélnél.

A fájlt jobb a felhasználók (vagy a globális célközönség legtöbb felhasználója) közelében tárolni, hogy a fájl gyorsan letölthető legyen.

További lépések

Tippek és bevált gyakorlatok a vászonalapú alkalmazások teljesítményének javításához

Kapcsolódó információk

A vászonalapú alkalmazás végrehajtási fázisainak és adathívási folyamatainak ismertetése
A vászonalapú alkalmazások gyenge teljesítményének gyakori forrásai
Gyakori problémák és megoldások a Power Apps-alkalmazásokhoz
Indítási problémák elhárítása a Power Apps esetében

Megjegyzés

Megosztja velünk a dokumentációja nyelvi preferenciáit? Rövid felmérés elvégzése. (ne feledje, hogy ez a felmérés angol nyelvű)

A felmérés elvégzése körülbelül hét percet vesz igénybe. Semmilyen személyes adatot nem gyűjtünk (adatvédelmi nyilatkozat).