Kaaviosovelluksen yleiset suorituskykyongelmat ja ratkaisut

Voit luoda kaaviosovelluksia erilaisilla tietolähteillä. Valitse tietolähde ja yhdistin sen mukaan, mitä liiketoiminnan tarpeita ja skenaarioita varten sovellus suunnitellaan. Yrityssovellusten osalta Microsoft Dataverse on suositeltava tietolähde, koska siitä on useita suorituskykyetuja. Sovelluksissa, joissa on muutama tapahtuma, voit käyttää kaikkia muita käytettävissä olevia tietolähteitä ympäristössäsi.

Kun otetaan huomioon sovelluksen suorituskykyyn liittyvät seikat, mieti, kuinka monta käyttäjää sovellus tulee käyttämään, kun sovellus on julkaistu; luonti-, nouto-, päivitys- ja poistotapahtumien (CRUD) määrä; tietojen vuorovaikutuksen tyyppi; maantieteellinen käyttö; ja käyttäjällä olevien laitteiden tyypit.

Tässä artikkelissa on tietoja yleisimmistä suorituskykyongelmista, jotka voivat hidastaa kaaviosovellusten toimintaa, ja kyseisten ongelmien ratkaisusta. Näiden tietojen avulla voit parantaa sovelluksen suorituskykyä liiketoimintasuunnitelman ja yrityksen kasvun mukaan.

Aluksi käsitellään joitakin yleisiä suorituskykyongelmia, joita esiintyy riippumatta siitä, mitä yhdistimiä käytetään. Myöhemmissä osissa on tietoja suorituskykyongelmista ja yhdistinkohtaisista ratkaisuista.

Varmista ennen aloittamista, että tunnet kaaviosovelluksen suoritusvaiheet ja tietokutsun työnkulun. Tutustu myös kohtaan Yleisimmät syyt kaaviosovellusten hitaaseen suorituskykyyn, jossa on tietoja yleisiä ongelmista, jotka ovat välttävissä kaaviosovelluksia suunniteltaessa tai päivitettäessä.

Suuret tietojoukot latautuvat hitaasti eri ympäristöissä

Sovelluksen suorituskyky voi vaihdella, kun suuria tietojoukkoja ladataan eri ympäristöissä, kuten iOS- tai Android-ympäristöissä. Tämä variaatio johtuu eri verkkopyyntörajoituksista kussakin ympäristössä. Ympäristöt voivat esimerkiksi sallia eri määrän samanaikaisia verkkopyyntöjä. Tämä ero voi vaikuttaa merkittävästi suurten tietojoukkojen latausaikaan.

Tämän vuoksi onkin suositeltavaa ladata vain tiedot, jotka on näytettävä heti näytössä. Muiden tietojen osalta voi käyttää sivutusta ja välimuistiin tallennusta. Lisätietoja: Vihjeitä ja parhaita käytäntöjä kaaviosovellusten suorituskyvyn parantamiseen

Liian monta saraketta noudetaan

On suositeltavaa valita vain sovelluksen kannalta välttämättömät sarakkeet. Jos sarakkeita lisätään tietolähteestä enemmän (tai kaikki sarakkeet lisätään), kaikki sarakkeiden tiedot ladataan. Tämä toiminto aiheuttaa suuren määrän kutsuja verkossa ja siksi myös asiakaslaitteessa käytetään paljon muistia. Tämä ongelma voi vaikuttaa mobiililaitteiden käyttäjiin vielä enemmän, jos verkon kaistanleveyttä on rajoitettu tai jos laitteella on rajoitetusti muistia tai vanha suoritin.

Jos sovelluksen tietolähteenä on esimerkiksi Dataverse, varmista, että olet ottanut Eksplisiittinen sarakkeiden valinta -toiminnon käyttöön. Power Apps voi rajoittaa tämän toiminnon avulla tietojen haun vain sovelluksessa käytettyihin sarakkeisiin.

Voit ottaa eksplisiittisen sarakkeiden valintatoiminnon käyttöön kaaviosovelluksessa valitsemalla Asetukset > tulevat ominaisuudet > esikatselun ja kytkin sitten Eksplisiittisen sarakkeiden valinnan painikkeeksi.

Selaimet, joita ei tueta, tai vanhat selaimet

Käyttäjät, jotka käyttävät vanhoja selaimia tai selaimia, joita ei tueta, saattavat kohdata suorituskykyongelmia. Varmista, että käyttäjät käyttävät pohjaan perustuvien sovellusten yhteydessä vain tuettuja selaimia.

Hidas suorituskyky maantieteellisen etäisyyden vuoksi

Ympäristön maantieteellinen sijainti ja tietolähteen etäisyys käyttäjistä voi vaikuttaa suorituskykyyn.

Tämän on suositeltavaa, että ympäristö sijaitsee käyttäjien lähellä. Vaikka Power Apps käyttää sisällön osalta Azure-sisältöverkkoa, tietokutsut noutavat tiedot edelleen tietolähteestä. Jos tietolähde sijaitsee toisessa maantieteellisessä sijainnissa, se voi vaikuttaa sovelluksen suorituskykyyn.

Suuri maantieteellinen etäisyys vaikuttaa suorituskykyyn eri tavoin. Kyse voi olla esimerkiksi viiveestä, pienentyneestä siirtomäärästä, pienemmästä kaistanleveydestä ja pakettien katoamisesta.

Sallittujen kohteiden luetteloa ei ole määritetty

Varmista, että tarvittavia palvelun URL-osoitteita ei ole estetty tai että ne on lisätty palomuurin sallittujen osoitteiden luetteloon. Täydellinen luettelo kaikista palveluiden URL-osoitteista, jotka on sallittava Power Appsissa, on kohdassa Pakolliset palvelut.

Ei-delegoitujen toimintojen käyttö ja ei-delegoitujen kyselyjen soveltumattomien tietorivien rajoitukset

Delegoitavilla toiminnoilla tietojen käsittely delegoidaan tietolähteelle, mikä minimoi resurssitarpeen asiakaspäässä. Jos delegointi ei ole mahdollista, voit rajoittaa ei-delegoitavien kyselyjen tietojen rivirajoitusta niin, että palvelinpohjaisesta yhteydestä palautettujen rivien määrä pysyy optimaalisena.

Ei-delegoitavien toimintojen käyttö ja ei-delegoitavien kyselyjen tietojen rivirajoitukset lisäävät tiedonsiirron resurssitarpeita. Tämä johtaa vastaanotettujen tietojen muokkaamisen JS-pinoksi asiakaspäässä. Varmista, että sovelluksessa käytetään delegoitavissa olevia toimintoja aina, kun se on mahdollista, ja että ei-delegoitavissa kyselyissä käytetään optimaalista tietojen rivirajoitusta.

Lisätietoja: Delegoinnin käyttö, Delegoinnin yleiskatsaus.

OnStart-tapahtuma tarvitsee hienosäätöä

OnStart-tapahtuma suoritetaan, kun sovellus ladataan. Kun sovelluksen OnStart-ominaisuuden toiminnoissa kutsutaan suuria tietomääriä, sovellus latautuu hitaasti. Näytön hidastuminen vaikuttaa näyttöön, joka on merkittävissä määrin riippuvainen toisessa näytössä määritetyistä ohjausobjekteista ja arvoista.

Seuraavissa osissa käsitellään yleisiä tällaisissa tilanteissa koettuja ongelmia.

Suuri kutsujen määrä OnStart-tapahtumassa hidastaa sovelluksen käynnistymistä

Yrityksessä keskitettyihin tietolähteisiin tehtyjen kutsujen määrä voi aiheuttaa palvelimeen pullonkaulan tai resurssiristiriitoja.

Tietokutsut voidaan optimoida käyttämällä välimuistimekanismia. Monet käyttäjät voivat käyttää yhtä sovellusta, minkä vuoksi palvelimen päätepisteissä on useita käyttäjäkohtaisia tietokutsuja. Nämä tietokutsut voivat olla aiheuttaa pullonkaulan tai pakotetun rajoittamisen.

OnStart-tapahtuman viive raskaiden komentosarjojen vuoksi

OnStart-tapahtuman raskaat komentosarjat ovat yksi tavallisimmista virheistä kaaviosovelluksia suunniteltaessa. Vain sellaiset tiedot kannattaa hakea, joita tarvitaan sovelluksen käynnistämiseen.

OnStart-tapahtuman kaava kannattaa optimoida. Jotkin toiminnat voidaan esimerkiksi siirtää OnVisible-ominaisuuteen. Tällä tavoin sovelluksen käynnistyminen nopeutuu ja muita vaiheita voidaan jatkaa, kun sovellus avautuu.

Lisätietoja: OnStart-ominaisuuden optimointi

Muistiin kohdistuva paine asiakaspuolella

Kaaviosovellusten käyttämän muistin määrä on tärkeä tarkistaa, sillä sovellus suoritetaan useimmin mobiililaitteessa. Pinon muistipoikkeukset ovat kaatuvan tai jumittuvan kaaviosovelluksen todennäköisin syy tietyissä laitteissa.

JavaScript (JS) -pino saattaa ylittää kokorajoituksen, koska asiakaspuolella on käynnissä raskaita komentosarjoja, joilla lisätään, suodatetaan, lajitellaan tai ryhmitellään sarakkeita. Useimmissa tapauksissa asiakasohjelman pinon muisti ei riitä -poikkeukset voivat käynnistää sovelluksen kaatumisen tai jumiutumisen.

Jos tietojen lähteenä on esimerkiksi Dataverse tai SQL Server, Näkymä-objektin avulla voidaan varmistaa, että liittäminen, suodatus, ryhmittely tai lajittelu tapahtuu palvelinpuolella asiakaspuolen sijasta. Tämä tapa vähentää kyseisten toimintojen komentosarjojen resurssivaatimuksia asiakasohjelmassa.

Jos asiakasta kuormittavat toiminnot, kuten JOIN tai Ryhmittely, tapahtuvat asiakaspuolella tietojoukossa, jossa on yli 2 000 tietuetta, pinon objektit lisääntyvät, jolloin muistirajat ylittyvät.

Useimpien selainten sovelluskehittäjien työkaluilla voit profiloida muistin. Se auttaa visualisoimaan pinon koon, tiedostot, solmut ja kuuntelijat. Sovelluksen suorituskyky profiloidaan selaimen avulla, missä on lisätietoja kohdassa Microsoft Edge (Chromium) -kehittäjien työkalujen yleiskatsaus. Tarkista skenaariot, jotka ylittävät JS-pinon muistin raja-arvon. Lisätietoja: Muistiongelmien korjaaminen

SQL Server -yhdistimen suorituskykyä koskevat huomioon otettavat seikat

Power Appsin SQL Server -yhdistimen avulla voidaan muodostaa yhteys paikalliseen SQL Serveriin tai Azure SQL Databaseen. Tässä osassa käsitellään yleisiä tämän kaaviosovelluksen yhdistimen käyttöä koskevia suorituskykyongelmia ja niiden ratkaisuja. Lisätietoja: Yhdistäminen Power Appsista SQL Serveriin, Kaaviosovelluksen luonti Azure SQL Database -tietokannasta

Seuraavaksi tarkastellaan yleisiä suorituskykyongelmia, joita esiintyy käytettäessä kaaviosovellusten SQL Server -yhdistintä, ja niiden ratkaisuja.

N+1 -kysely

Valikoimat, jotka tuottavat liian monta pyyntöä palvelimiin, aiheuttavat N+1-kyselyongelmia. N+1-kyselyongelma on yksi yleisimmistä ongelmista Valikoima-ohjausobjektia käytettäessä.

Ongelma voi välttää käyttämällä näytä objektit SQL:n taustatoiminnoissa tai muuttaa käyttöliittymäskenaarioita.

Taulukon tarkistus indeksin haun sijaan

Sovellus saattaa hidastua, jos sovelluksen käyttämät toiminnot käyttävät tietokannassa kyselyjä, joiden tuloksena on taulukon tarkistuksia indeksin haun sijaan. Lisätietoja: Vihjeet, taulukon SCAN-tarkistus ja indeksin SEEK-haku

Tällaiset ongelmat voi ratkaista käyttämällä kaavassa StartsWith-funktiota eikä IN-operaattoria. Kun SQL-tietolähteessä käytetään StartsWith-operaattorin, tuloksena on indeksin haku. IN-operaattoria käytettäessä tuloksena on indeksin tai taulukon tarkistus.

Hitaat kyselyt

SQL-tietokannan hitaat kyselyt ja indeksit voidaan profiloida ja niitä voidaan tarkentaa. Jos kaava esimerkiksi hakee tietystä sarakkeesta tietyt tiedot laskevassa (DESC) järjestyksessä, lajittelusarakkeessa on oltava laskevassa järjestyksessä oleva indeksi. Indeksiavain luo oletusarvoisesti nousevan (ASC) järjestyksen.

Voit myös tarkistaa tietopyyntöjen URL-osoitteen. Esimerkiksi seuraava tietopyyntökatkelma (osittainen OData-kutsu) pyytää SQL-tietokantaa palauttamaan 500 tietuetta, joiden sarake vastaa arvoa ja järjestys on tunnuksen mukaan laskevassa järjestyksessä.

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

Tämä auttaa hahmottamaan vastaavanlaisen pyynnön ehdot kattavat indeksivaatimukset. Jos tässä esimerkissä Tunnus-sarakkeen indeksi on oltava laskevassa järjestyksessä, kysely suorittaminen nopeutuu.

Tarkista hitaiden kyselyjen suoritussuunnitelmasta, onko taulukon tai indeksin tarkistus luotu aiemmin. Seuraa suoritussuunnitelman avainhaun liiallisia kustannuksia.

Lisätietoja:

• Suorituskyvyn valvominen ja säätäminen
• Suorituskyvyn seuranta kyselysäilön avulla
• Laajennettujen tapahtumien yleiskatsaus

Tietokantaresurssien ristirita

Varmista, että tietolähteessä, —joka on SQL-tietokanta—, ei ole resurssiristiriitoja, kuten suorittimen pullonkauloja, I/O-ristiriitoja, muistipainetta tai tempDB-ristiriitaa. Tarkista myös lukitukset, odotukset, lukitustilat ja kyselyjen aikakatkaisut.

Raskas asiakasohjelma tai liikaa pyyntöjä

Sovellus, joka suorittaa Ryhmittelyperuste-, Suodatusperuste- tai JOIN-toimintoja asiakaspäässä, käyttää asiakaslaitteiden suoritin- ja muistiresursseja. Tietojen koon mukaan näiden toimintojen komentosarjat saattavat kestää kauemmin asiakaspuolella, mikä kasvattaa asiakaspään JS-pinon kokoa. Ongelma laajenee paikallista tietolähdettä käytettäessä, koska kukin tietojen valintakutsu siirtyy tietolähteeseen tietoyhdyskäytävän kautta.

Tällaisissa tilanteissa kannattaa käyttää SQL-tietokannan Näytä-objektia Ryhmittelyperuste-, Suodatusperuste- tai JOIN-toiminnoissa. Näkymät voivat käyttää valikoivia sarakkeita ja poistaa tarpeettomia sarakkeita, joissa on suuria tietotyyppejä, kuten NVARCHAR(MAX), VARCHAR(MAX) ja VARBINARY(MAX).

Asiakasohjelmaan siirrettyjen tietojen koko

Kaaviosovellus näyttää oletusarvoisesti tiedot käyttämällä taulukoita tai näkymiä käytettävissä olevista tietokantaobjekteista. Kaikkien sarakkeiden hakeminen taulukosta voi hidastaa vastausta, erityisesti käytettäessä suuria tietotyyppejä, kuten NVARCHAR(MAX).

Suurten tietomäärien siirtäminen asiakkaille vie aikaa. Tämä siirto johtaa myös komentosarjojen suoritusajan kasvamiseen niin, että JS-pinossa on paljon tietoja asiakaspuolella, kuten on kuvattu aiemmin tässä artikkelissa.

Asiakkaaseen siirrettävien tietojen määrää voi vähentää käyttämällä näkymiä, jotka sisältävät sovelluksen edellyttämät sarakkeet, ja varmistamalla, että eksplisiittinen sarakevalinta on otettu käyttöön aiemmin tässä artikkelissa kuvatulla tavalla.

Paikalliseen SQL Serveriin liittyviä seikkoja

Jos kaaviosovellukset käyttävät SQL Server -yhdistintä ja paikallista tietoyhdyskäytävää, suorituskyky saattaa heiketä monin tavoin. Tässä osassa on luettelo yleisistä suorituskykyongelmista ja ratkaisuista, jotka liittyvät paikallisen tietokantalähteen käyttämiseen.

Paikallinen tietoyhdyskäytävä, joka ei ole kunnossa

Organisaatiot voivat määrittää useita solmuja paikallisille yhdyskäytäville. Vaikka jokin solmuista ei olisikaan tavoitettavissa, tietopyynnöt virheellisesti toimivaan solmuun eivät palauta tulosta hyväksyttämällä ajassa tai seurauksena voi olla ei tavoiteta -virhesanomia jonkin aikaa odottamisen jälkeen.

Varmista, että paikallisen tietoyhdyskäytävän kaikki solmut ovat kunnossa. Varmista myös, että solmujen ja SQL-esiintymän välille on määritetty pienin verkon viive.

Paikallisen tietoyhdyskäytävän sijainti

Tietoyhdyskäytävä edellyttää verkkokutsuja paikallisiin tietolähteisiin, jotta OData-pyynnöt voidaan tulkita. Tietoyhdyskäytävän on esimerkiksi ymmärrettävä tietotaulukon rakenne, jotta OData-pyynnöt voidaan kääntää SQL-tietojen käsittelykielen (DML) lausekkeiksi. Ylimääräiset resurssikustannuksia tulee, kun tietoyhdyskäytävä on määritetty erilliseen sijaintiin, jossa tietoyhdyskäytävän ja SQL-esiintymän välinen verkon viive on suuri.

Yritysympäristössä suositellaan skaalautuvaa tietoyhdyskäytäväklusteria, kun odotetaan suuria määriä tietopyyntöjä. Tarkista, kuinka monta yhteyttä tietoyhdyskäytävän solmujen ja SQL-esiintymän välille on muodostettu.

Kun paikallisen tietoyhdyskäytävän tai SQL-esiintymän samanaikaiset yhteydet tarkistetaan, organisaatio voi määrittää, missä tietoyhdyskäytävän on skaalauduttava ja kuinka monta solmua on kyseessä.

Tietoyhdyskäytävän skaalautuvuus

Jos aiot käyttää suurta tietomäärää paikallisen tietoyhdyskäytävän kautta, yksittäinen käytössä oleva paikallinen tietoyhdyskäytäväsolmu voi muodostua pullonkaulaksi, kun yritetään käsitellä niin suuri pyyntöjen määrä.

Paikallisen tietoyhdyskäytävän yksittäinen solmu voi riittää käsittelemään enintään 200 samanaikaista yhteyttä. Jos nämä kaikki samanaikaiset yhteydet kuitenkin suorittavat kyselyjä aktiivisesti, muut pyynnöt jäävät odottamaan käytettävissä olevia yhteyksiä.

Lisätietoja sen varmistamisesta, että paikallinen tietoyhdyskäytävä skaalautuu tieto- ja kyselymäärän mukaisesti on kohdassa Paikallisen tietoyhdyskäytävän suorituskyvyn valvonta ja optimointi.

Azure SQL Database -tietokantaan liittyviä seikkoja

Kaaviosovellukset voivat muodostaa yhteyden Azure SQL Databaseen SQL Server -yhdistimen avulla. Yleinen suorituskykyongelmien syy Azure SQL Databasea käytettäessä on väärän tason valitseminen liiketoimintatarpeita varten.

Azure SQL Databasea voi käyttää eri palvelutasoilla, siten että eri liiketoimintatarpeita vastaavat ominaisuudet ovat erilaisia. Lisätietoja tasoista on Azure SQL Database -dokumentaatiossa.

Kun käytössä on raskaita tietopyyntöjä, valitun tason resursseja saatetaan rajoittaa heti, kun raja-arvo saavutetaan. Tällainen rajoittaminen heikentää seuraavien kyselyjen suorituskykyä.

Tarkista Azure SQL Databasen palvelutaso. Alemmalla tasolla on joitakin rajoituksia. Suorituskyvyn kannalta suoritin, IO-siirtonopeus ja viive ovat tärkeitä. Tämän vuoksi SQL-tietokannan suorituskyky kannattaa tarkistaa säännöllisesti. Lisäksi on tarkistettava, ylittääkö resurssien käyttö raja-arvon. Esimerkiksi paikallinen SQL Server määrittää suorittimen käytön raja-arvoksi yleensä noin 75 prosenttia.

SharePoint-yhdistimen suorituskykyä koskevat huomioon otettavat seikat

SharePoint-yhdistimen avulla voit luoda sovelluksia Microsoft-luetteloiden tietojen avulla. Voit myös luoda kaaviosovelluksia suoraan luettelonäkymästä. Seuraavaksi tarkastellaan yleisiä suorituskykyongelmia, joita esiintyy käytettäessä kaaviosovellusten SharePoint-tietolähdettä, ja niiden ratkaisuja.

Liian monta dynaamista valintasaraketta

SharePoint tukee erilaisia tietotyyppejä, mukaan lukien dynaamisia valintoja, kuten Henkilö, Ryhmä ja Laskettu. Jos luettelo määrittää liian monta dynaamista saraketta, näiden dynaamisten sarakkeiden käsitteleminen SharePoint issa kestää kauemmin, ennen kuin tiedot palautetaan kaaviosovellusta suorittavalle asiakkaalle.

Älä käytä liikaa dynaamisia valintasarakkeita SharePointissa. Tämä ylikäyttö voi aiheuttaa tietojen käsittelyn vältettävissä olevia ja ylimääräisiä resurssitarpeita SharePoint-pään tietojen käsittelylle. Sen sijaan voi käyttää staattisia sarakkeita esimerkiksi sähköpostitunnusten tai henkilöiden nimien säilyttämiseen.

Kuvasarake ja liite

Kuvan ja liitetyn tiedoston koko voivat aiheuttaa vastausten hidastumisen, kun tietoja noudetaan asiakkaaseen.

Tarkista luettelo ja varmista, että vain tarvittavat sarakkeet on määritetty. Luettelossa olevien sarakkeiden määrä vaikuttaa tietopyyntöjen suorituskykyyn. Tämä johtuu siitä, että vastaavat tietueet tai määritetyille tietorivin rajoituksille määritetyt tietueet noudetaan ja lähetetään takaisin asiakkaaseen kaikille luettelossa määritetyille sarakkeille —– riippumatta siitä, käyttääkö sovellus kaikkia tietoja vai ei.

Kysely voidaan kohdistaa vain sovelluksen käyttämiin sarakkeisiin ottamalla käyttöön eksplisiittinen sarakkeiden valintatoimintoa aiemmin tässä artikkelissa kuvatulla tavalla.

Suurikokoiset luettelot

Jos käytössä on suuri luettelo, jossa on satojatuhansia tietueita, luettelon voi osioida tai sen voi jakaa useisiin luetteloihin esimerkiksi luokkien tai päivämäärän ja ajan perusteella.

Tiedot voidaan tallentaa eri luetteloihin esimerkiksi vuosittain tai kuukausittain. Siinä tapauksessa sovellus voidaan suunnitella siten, että käyttäjä voi valita aikaikkunan, joka noutaa tiedot alueen sisällä.

Hallitussa ympäristössä suorituskyvyn vertailutesti on osoittanut, että Microsoft-luetteloihin tai SharePointiin liittyvien OData-pyyntöjen suorituskyky liittyy erittäin paljon luettelon sarakkeiden lukumäärään ja noudettavien rivien lukumäärään ( tietorivien yläraja ei-delegoitaville kyselyille). Kun sarakkeita on vähemmän ja tietorivirajan asetus on pienempi, kaaviosovelluksen suorituskyky voi parantua.

Käytännön kannalta sovellukset on kuitenkin suunniteltu tiettyjen liiketoimintarpeiden mukaisesti. Tietorivirajan tai luettelon sarakkeiden määrän vähentäminen ei ehkä ole helppoa eikä nopeaa. OData-pyyntöjä kannattaa kuitenkin valvoa asiakaspuolella sekä säätää ei-delegoitaville kyselyille tietorivien määrää ja luettelon sarakkeiden määrää.

Dataversea tietolähteenä käytettäessä huomioon otettavat suorituskykyyn liittyvät seikat

Kun käytät Microsoft Dataversea tietolähteenä, tietopyynnöt menevät suoraan ympäristön ilmentymään, eikä niitä tarvitse siirtää Azuren API-hallinnan kautta. Lisätietoja: Tietokutsun työnkulku muodostettaessa yhteys Microsoft Dataverseen

Dataverseen yhdistetty kaaviosovellus voi toimia hitaasti, jos se suorittaa raskaita komentosarjoja, kuten Suodatusperuste tai JOIN, palvelinpään sijaan asiakkaassa.

Käytä Dataverse-näkymiä, jos mahdollista. Näkymän, jossa on tarvittavat liitos- tai suodatusehdot, avulla voit pienentää resurssitarvetta verrattuna kokonaisen taulukon käyttöön. Jos sinun on esimerkiksi liitettävä taulukoita ja suodatettava niiden tietoja, voit määrittää näkymän liittämällä ne ja määrittämällä vain tarvittavat sarakkeet. Tätä näkymää voi käyttää sitten sovelluksessa, jossa se edellyttää resursseja liitos- tai suodatustoimintaan palvelinpäässä eikä asiakaspäässä. Tämä tapa vähentää paitsi ylimääräisiä toimintoja, myös tietojen siirtoa. Tietoja suodatusehtojen muokkaamista ja lajittelemista varten on kohdassa Suodatusehtojen muokkaaminen.

Excel-yhdistimen suorituskykyä koskevat huomioon otettavat seikat

Excel-yhdistimellä voi muodostaa yhteyden kaaviosovelluksesta Excel-tiedostossa olevan taulukon tietoihin. Tällä yhdistimellä on rajoituksia muihin tietolähteisiin verrattuna, —kuten rajoitetut delegoitavat toiminnot, mikä —rajoittaa kaaviosovelluksen taulukosta lataamat tiedot enintään 2 000 tietueeseen. Jos haluat ladata yli 2 000 tietuetta, jaa tiedot eri tietotaulukoihin muina tietolähteinä.

Seuraavaksi tarkastellaan yleisiä suorituskykyongelmia, joita esiintyy käytettäessä Exceliä kaaviosovellusten tietolähteenä, ja niiden ratkaisuja.

Liian monta tietotaulukkoa ja suuri tietojen koko

Sovelluksen suorituskyky voi hidastua, jos sen käyttämällä Excel-tiedostossa on liian monta tietotaulukkoa tai jos tietotaulukoissa on erittäin paljon tietoja useissa sarakkeissa. Excel-tiedosto ei ole relaatiotietokanta tai tietolähde, joka sisältää delegoitavia toimintoja. Power Appsin on ladattava tiedot ensin määritetyistä tietotaulukoista ja käyttää sitten esimerkiksi seuraavia toimintoja: Filter, Sort, JOIN, Group by ja Search.

Jos tietotaulukkoja, joissa on paljon rivejä ja sarakkeita, on liian monta, sillä on vaikutus sovelluksen suorituskykyyn ja asiakaspuolen resurssivaatimuksiin, koska jokaista tietotaulukkoa on käsiteltävä JS-pinossa. Tämä vaikutus johtaa myös siihen, että sovellus kuluttaa enemmän asiakaspuolen muistia.

Jotta tämä ongelma ei vaikuttaisi sovellukseen, on varmistettava, että vain tarvittavat Excel-tiedoston tietotaulukon sarakkeet määritetään.

Raskaat tapahtumat

Excel ei ole relaatiotietokantajärjestelmä. Excel hallitsee sovelluksen tekemiä muutoksia samalla tavalla kuin jos kyse olisi Excel-tiedoston tietoja muuttavasta käyttäjästä. Jos sovelluksessa on paljon lukutoimintoja mutta vähän CRUD-toimintoja, se voi toimia tehokkaasti. Jos sovellus suorittaa raskaita tapahtumia, se voi kuitenkin vaikuttaa haitallisesti sovelluksen suorituskykyyn.

Tapahtumien määrälle ei ole tiettyä raja-arvoa, koska myös käsiteltävillä tiedoilla on merkitystä. Sovelluksen suorituskykyyn vaikuttavat myös monet muut seikat, kuten verkon resurssivaatimukset tai käyttäjän laite.

Jos sinulla on vain luku -tietoja, voit tuoda kyseiset tiedot sovellukseen paikallisesti sen sijaan, että lataat ne tietolähteestä. Yrityssovelluksissa kannattaa käyttää tietolähteinä sen sijaan Dataversea, SQL Serveriä tai SharePointia.

Tiedoston koko

Valittavana on erilaisia pilvitallennustilan vaihtoehtoja, —joissa on vaihteleva tai määritettävä— Excel-tiedoston tallennuskapasiteetti. Jos kyse on kuitenkin yhdestä suuresta kaikki taulukot sisältävästä Excel-tiedostosta, sovelluksen resurssivaatimukset suurenevat tiedostoa ladattaessa ja luettaessa tietoja, jotka ladataan asiakaspuolelle.

Yhden suuren tiedoston käyttämisen sijaan tiedot kannattaa jakaa useisiin Excel-tiedostoihin, joissa on mahdollisimman vähän tietotaulukoita. Yhteys muodostetaan silloin kuhunkin tiedostoon vain silloin, kun sitä tarvitaan. Näin tietojen lataaminen tietotaulukosta tapahtuu fragmentteina, mikä vähentää monien taulukoiden tai suuren tietojoukon lataamisen resurssivaatimuksia.

Tiedoston sijainti

Tietolähteen maantieteellinen sijainti ja sen etäisyys asiakkaan sijainneista voi aiheuttaa sovellukseen suorituskyvyn pullonkauloja ja johtaa verkon viiveeseen. Tämä vaikutus voi vahvistua, jos käytössä on mobiiliasiakas, jonka yhteyksien kaistanleveyttä on rajoitettu.

Tiedosto kannattaa säilyttää käyttäjien lähellä (tai maailmanlaajuisessa käytössä useimpien käyttäjien lähellä), jotta tiedosto voidaan ladata nopeasti.

Seuraavat vaiheet

Vihjeitä ja parhaita käytäntöjä pohjaan perustuvan sovelluksen suorituskyvyn parantamiseen

Katso myös

Tietoja pohjaan perustuvan sovelluksen suoritusvaiheista ja tietokutsujen työnkulusta
Yleisimmät syyt kaaviosovellusten hitaaseen suorituskykyyn
Power Appsin yleisiä ongelmia ja ratkaisuja
Power Appsin käynnistysongelmien vianmääritys