Lassú a riport? – teljesítmény-optimalizálás a gyakorlatban

A lassú riportot a felhasználók egyszerűen nem használják. Szerencsére a lassulás okai néhány visszatérő mintára vezethetők vissza – ez az útmutató sorra veszi őket, a mérésével kezdve.

Költségbecslés indítása Adatmodellezés és DAX

Olvasási idő 9 perc | Utolsó frissítés: 2026. szeptember 9.

Röviden

Teljesítmény röviden

A lassú riportot nem használják. A lassulás okai három rétegben keresendők: az adatmodellben, a DAX-számításokban és a riportoldal felépítésében. A tapasztalat szerint a legnagyobb nyereség szinte mindig a modell szintjén érhető el – ezért érdemes ott kezdeni, nem a vizuálok igazgatásával.

Az első lépés viszont mindig a mérés: enélkül találgatás az egész.

1. lépés

Először mérjünk

  • Performance Analyzer (Power BI Desktop, Nézet menü): oldalfrissítés után vizuálonként megmutatja, mennyi idő ment a DAX-lekérdezésre és mennyi a megjelenítésre. Ez azonnal megmondja, melyik vizuál a szűk keresztmetszet.
  • DAX Studio (ingyenes külső eszköz): a Performance Analyzerből kimásolt lekérdezés itt részletesen elemezhető – látszik a lekérdezésterv és a szkennelt sorok száma.
  • VertiPaq Analyzer (a DAX Studio része): megmutatja, melyik tábla és melyik oszlop foglalja a memóriát. Gyakran egyetlen felesleges, nagy kardinalitású oszlop viszi el a modell méretének felét.
  • Tabular Editor: modellszintű átalakításokhoz és a bevált gyakorlatok automatikus ellenőrzéséhez (Best Practice Analyzer).

Mit tekintsünk elfogadhatónak?

Gyakorlati elvárás, hogy egy riportoldal 5 másodpercen belül betöltsön, és egy szűrőkattintás 2–3 másodpercen belül lefusson. Ha ennél lassabb, a felhasználók előbb-utóbb visszatérnek az Excelhez.

2. lépés

Modellszintű okok – itt a legnagyobb nyereség

  • Felesleges oszlopok: minden oszlop memóriát foglal, akkor is, ha egyetlen vizuál sem használja. A megjegyzés-, azonosító- és időbélyeg-oszlopok a leggyakoribb bűnösök.
  • Nagy kardinalitás: a sok egyedi értéket tartalmazó oszlop rosszul tömörödik. Egy másodperc pontosságú időbélyeget érdemes dátumra és külön időoszlopra bontani.
  • Automatikus dátumhierarchia: a Power BI minden dátumoszlop mögé rejtett táblát generál. Kapcsolja ki (Beállítások → Adatok betöltése), és használjon egy közös dátumtáblát.
  • Lapos, egyetlen nagy tábla: a csillagséma nemcsak elméleti szépség, hanem gyorsabb is – a motor erre van optimalizálva.
  • Kétirányú kapcsolatok: bonyolítják a lekérdezési tervet. Csak indokolt esetben.
  • Túl hosszú történet: tényleg kell 10 év adata, ha a riport 2 évet mutat? A szűrést a forrásnál végezze el.
3. lépés

DAX-szintű okok

  • Számított oszlop mérték helyett: a számított oszlop minden sorra tárolódik. Ha az érték a szűrőktől függ, mérték kell.
  • Iterátorok nagy táblán: a SUMX, FILTER soronként dolgozik. Ahol lehet, használjon egyszerű aggregációt, vagy készítse elő az értéket a forrásban.
  • FILTER a CALCULATE-ben: egyszerű feltételnél elég az oszlopszűrő – CALCULATE([Árbevétel], Termek[Kategoria] = "A") gyorsabb, mint ugyanez FILTER(ALL(...)) formában.
  • Ismételt számítás: ha ugyanaz a részeredmény többször kell, tegye VAR változóba – egyszer számolódik ki.
  • Bonyolult képlet vizuálszűrőben: a mértékre alkalmazott szűrés minden sorra kiértékelődik – ez a leggyakoribb „miért tart 30 másodpercig egy táblázat" ok.
DAX – ugyanaz gyorsabban
-- Lassabb: felesleges FILTER a teljes táblán
Árbevétel A =
CALCULATE( [Árbevétel], FILTER( ALL( Termek ), Termek[Kategoria] = "A" ) )

-- Gyorsabb: egyszerű oszlopszűrő
Árbevétel A =
CALCULATE( [Árbevétel], REMOVEFILTERS( Termek ), Termek[Kategoria] = "A" )

-- Változó: a részeredmény egyszer számolódik ki
Növekedés % =
VAR Most  = [Árbevétel]
VAR Elozo = [Árbevétel EV]
RETURN DIVIDE( Most - Elozo, Elozo )
4. lépés

Vizuálszintű okok

  • Túl sok vizuál egy oldalon: minden vizuál külön lekérdezést indít. 6–8 felett érezhető a lassulás.
  • Nagy táblázatok és mátrixok: több ezer soros táblázat megjelenítése költséges – és értelmetlen, mert senki nem olvassa végig. Használjon fúrási oldalt.
  • Sok szeletelő: minden szeletelő is lekérdezés. Ha sok szűrő kell, tegye a szűrőpanelbe.
  • Egyedi (custom) vizuálok: egyes külső vizuálok lényegesen lassabbak a beépítetteknél – mérje meg őket.
  • Térképek nagy pontszámmal: több ezer pont kirajzolása lassú; érdemes összevonni (régió szintjén ábrázolni).
Külön téma

Ha nem a riport, hanem a frissítés lassú

Ez másik probléma, más megoldásokkal:

  • Query folding: ha a Power Query lépései visszahajlanak a forrásba, az adatbázis végzi a nehezét. Ellenőrizze a lépéseknél (View Native Query).
  • Inkrementális frissítés: csak a változott időszak töltődik újra – nagy tábláknál a legnagyobb nyereség.
  • Szűrés a forrásnál: ne hozzon be 10 év adatot, ha 2 kell.
  • Adatátjáró erőforrásai: ha a gateway gépe gyenge vagy túlterhelt, minden frissítés lassú lesz.
  • Sok, párhuzamos lekérdezés: a párhuzamos betöltés korlátozása néha gyorsít, ha a forrás nem bírja a terhelést.
Összefoglalás

Gyors ellenőrzőlista

  • Kikapcsolt automatikus dátumhierarchia, külön dátumtábla
  • Csillagséma, nem egyetlen lapos tábla
  • Csak a szükséges oszlopok vannak betöltve
  • Nincs másodperc pontosságú időbélyeg a modellben
  • A kapcsolatok egyirányúak, kivéve ahol indokolt
  • Az üzleti mutatók mértékek, nem számított oszlopok
  • Oldalanként legfeljebb 6–8 vizuál
  • Részletes táblázat külön fúrási oldalon
  • Nagy tábláknál inkrementális frissítés
  • A Performance Analyzer szerint minden vizuál 2 mp alatt lefut

Meglévő riportja lassú?

Az átvilágítás jellemzően rövidebb és olcsóbb, mint egy új riport építése. Írja le a kalkulátor beküldő űrlapján a helyzetet, és kérjen rá ajánlatot.

Kalkulátor indítása
GYIK

Gyakori kérdések

Segít, ha erősebb gépet veszek?▼
A fejlesztéshez igen (a Desktop memóriaigényes), de a közzétett riport sebességét a Service oldali erőforrás és maga a modell határozza meg. A felhasználó gépe csak a megjelenítést befolyásolja, a számítást nem.
A DirectQuery mindig lassabb?▼
Jellemzően igen, mert minden interakció lekérdezést küld a forrásnak, és a sebesség a forrásrendszertől függ. Jól indexelt adatbázissal és aggregációs táblákkal elfogadható teljesítmény érhető el, de import módban szinte mindig gyorsabb a riport.
Mekkora modell számít nagynak?▼
A sorok száma önmagában keveset mond – a memóriafoglalás a lényeg, amit a VertiPaq Analyzer mutat meg. Néhány millió soros ténytábla jó modellezéssel gond nélkül elfér a Pro keretében is; ugyanaz rossz szerkezettel viszont már a korlátot feszegetheti.
Mennyit lehet gyorsítani egy meglévő riporton?▼
Ha a riport soha nem esett át optimalizáláson, jellemzően nagyságrendi javulás érhető el – gyakran néhány óra munkával, elsősorban a modell megtisztításával. Ha a modell már rendben van, a további finomhangolás lényegesen több munkát igényel kisebb eredményért.
Kapcsolódó

Kapcsolódó útmutatók