I denne vejledning lærer du, hvordan du optimerer en måling i LuckyTemplates. Optimering af målinger i din rapport forbedrer effektiviteten af dine koder til at producere værdifuld indsigt og data. Du vil også lære om de forskellige evalueringsmetoder, og hvordan du anvender dem til at optimere din rapport. Du kan se den fulde video af denne tutorial nederst på denne blog.
Indholdsfortegnelse
1. Analyser kodens ydeevne
I dette eksempel skal du optimere denne rapport:
Dette er den datamodel, du vil bruge:
Jobtabellen indeholder alle oplysninger om ethvert job , der er blevet udført i en given tidsperiode.
Denne tabel er grundlaget for alle mål, som du vil optimere:
Først skal du teste rapportens ydeevne.
Gå til fanen Vis og vælg. Klik derefter på Start optagelse og opdatering af billeder . Vent på, at analysatoren gengiver det visuelle.
Når dette er gjort, skal du rulle ned listen Incitamentopdeling og klikke på Kopier forespørgsel .
Vælg derefter Eksterne værktøjer for at gå til DAX Studio og se på koden, som LuckyTemplates genererede.
Indsæt derefter den kopierede forespørgsel i arbejdsområdet.
Variabler i mål
Den første variabel er DateClosed , som er sliceren på dashboardet. Den bruger en kolonne fra faktatabellen til at få værdierne for bestemte perioder i udsnittet.
Den næste variabel er JobLost , som kontrollerer for False eller Blank af Job Lost-dataene.
Den sidste variabel er MatrixVisual . Dette er hjertet i koden. Det viser den opsummerede kolonne genereret af LuckyTemplates for at udfylde matrixvisuals. Den grupperer Job Loss Type i denne matrix og injicerer filtrene, der kommer fra udskærerne. Derefter tilføjer den udvidede kolonner.
Når opsummeringskolonnen afslutter udførelsen, vil du se resultaterne i ruden under koden.
LuckyTemplates bruger resultatet til at udfylde matrixvisuals.
Kold cache til DAX Studio
Dernæst skal du kontrollere den tid, det tager at udføre hele koden. For at gøre det skal du slå Server Timings til og derefter vælge Ryd cache og derefter køre .
Når du forsøger at optimere et mål i LuckyTemplates ved hjælp af, er det bedre at operere under den kolde cache, så den tid, du får, er korrekt. Tryk derefter på F5 og vent på, at handlingen er fuldført på fanen Server Timings .
Når det er færdigt, kan du se, at den samlede udførelsestid er 3,6 sekunder. Den brugte det meste af tiden i formelmotoren og brugte 57 millisekunder i lagermotoren
Du kan også se, at den fandt 383 lagringsmotorforespørgsler. Ud af alle disse forespørgsler er der 327, der er castet i hukommelsen, så de kan genbruges.
2. Analyser et mål i LuckyTemplates
Dernæst skal du optimere disse 3 identiske mål.
Du skal udtrække disse mål i en anden fil og forbinde den til den datamodel, du bruger.
Start derefter servertimingerne for at se den tid, det tager de 3 foranstaltninger i at udfylde visuals.
Resultaterne af kørslen viser, at foranstaltningerne bruger 1,85 sekunder på at hente et resultat.
Resultatet viser en tabel bestående af 10 rækker og 3 udvidede kolonner, som hører hjemme i de opsummerede kolonner.
Kolonnen Tabstype indeholder 10 unikke værdier, som koden beregner for at få incitamentsprocenterne.
Den tid, koden tager, er eksponentielt høj. Det er her og hvornår du skal optimere dem.
RB Incentive%-målet i LuckyTemplates
Dette er et RB Incentive%-mål i LuckyTemplates. Det er en af de 3 hovedmål, der bruges i dette eksempel.
Du kan se, at den forsøger at beregne incitamentsprocenten.
Den har en variabel, JobType, som henter Lost Type-værdi i den aktuelle filterkontekst. Den kontrollerer også, om der kun er en enkelt værdi synlig i den aktuelle filterkontekst. Du skal bruge en funktion, så hver gang en betingelse er opfyldt, giver den det tilsvarende resultat.
Denne målekode genererer en masse lagermotorfedt, hvilket øger tiden i kodens samlede varighed.
Gå nu tilbage til DAX Studio for at kontrollere mængden af storage-motorforespørgsler, som målingen genererer.
Du kan se, at det tog 600 millisekunder at udføre og 43 lagringsmotorforespørgsler at hente data for de 10 rækker.
Tjek nu de data, der anmodes om fra lagermotoren. I den første forespørgsel er der en jobtabstype og DCOUNT af jobtabstypen.
Den næste forespørgsel har Jobs Date Closed, som er fra udsnittet i rapporten.
I den tredje kode vil du se en anden jobtabstype med tilbagekaldsdata-id'et.
På en anden linje vil du se de vigtigste kodelinjer.
Den første ting du ser er jobbetalingen modtaget, faktureret og faktiske udgifter.
Dernæst er WHERE- funktionen, der angiver en betingelse og dets tilsvarende resultat. Resultatet vil variere baseret på valget af slicer og switch-sætningen i RB Incentive%-målet.
Du vil også bemærke, at koden på linje 12 og 14 er den samme.
Hvis du scroller til højre, kan du se, at der er linjer med de samme forespørgsler. Forespørgslerne på linjerne ledes af switch-sætningen i RB Incentive%-målet.
Hvis du går tilbage til RB Incentive%-målet i LuckyTemplates, kan du se antallet af gange, en forespørgsel gentages, og hvordan den afspejles i forespørgslerne i storage-motoren.
Logikken bag IF og switch
For nu at forstå, hvorfor forespørgslerne udføres flere gange, skal du forstå logikken i og SWITCH- funktioner.
Du skal udføre dem separat på en forespørgselsplan. Men før du gør det, skal du sørge for at oprette forbindelse til databasen og slå forespørgselsplanen til.
Udfør SWITCH- sætningen i forespørgselsplanen. Fremhæv derefter erklæringen, og tryk derefter på enter.
Dette vil generere en logisk forespørgselsplan med forskellige operationer.
Udfør derefter IF- sætningen ved at fremhæve sætningen og trykke på enter.
Du kan se, at det genererer den samme logiske forespørgselsplan.
Dette skyldes, at når du bruger en , konverterer motoren internt denne funktion til en IF -sætning. Men en SWITCH -sætning anbefales, fordi den øger læsbarheden af din kode.
Derefter skal du forstå, hvordan en kode udføres i IF- eller SWITCH -funktionen.
Dette er en eksempelkode, der har en SWITCH -sætning inde.
Den har mål for bruttofortjeneste, samlet skøn og samlet faktureret, som alle er SUMMEN for forskellige kolonner. Den har også en funktion over Jobs Loss Type og en SWITCH og TRUE -sætning.
Når du udfører denne kode, vil du se logikken bag funktionerne.
Den første forespørgsel får den særskilte jobtabstype fra jobtabellen.
Bortset fra jobtabstypen, får den også summen af jobestimatet.
Inde i WHERE- tilstanden kan du også se de værdier, der findes i kolonnen Jobtabstype.
3. Brug kodeevalueringsmetoder
I DAX er der 3 metoder til at evaluere koder:
Disse metoder hjælper dig med at optimere en kode eller et mål i LuckyTemplates.
1. metode: Streng evaluering
Eksemplet vist nedenfor bruger Strict Evaluation-metoden.
Logikken bag det er, at hvis konteksten for jobtabstypen er lig med A, vil den give bruttofortjenesten. Ellers giver det det samlede skøn. Koden gør dette for hver række i jobtabstypen.
Dette er et andet eksempel på mål i LuckyTemplates, der bruger Strict Evaluation.
Når du udfører denne kode, genererer den 5 storage engine-forespørgsler.
Med Strict Evaluation giver koden det samlede estimat, hvis bruttofortjenesten ganget med 1,4 er større end det gennemsnitlige estimat. Ellers vil det give Bruttofortjenesten.
Brug af Strict Evaluation producerer flere storage-motorforespørgsler, fordi IF -sætningen kontrollerer bruttofortjenestens konkurrence flere gange og i sidste ende vil hæmme udførelsen af hele operationen.
2. metode: Ivrig evaluering
Dette er den samme kode som det foregående eksempel.
Men i stedet for at beregne målene inde i IF- sætningen, beregnede den alt i før RETURN .
Det betyder, at før du kontrollerer erklæringerne, får den alle værdierne af bruttofortjenesten og totalestimat for alle jobtabstyper.
Når du udfører denne kode, reduceres antallet af lagermotorer til 3.
Det forbedrer ydelsen af hele operationen.
I den første operationsforespørgsel får den jobtabstypen og summen af jobestimat og bruttofortjeneste.
Den næste forespørgsel får summen af jobestimatet fra jobstalden. Dette bruges til at beregne det gennemsnitlige skøn.
Den sidste forespørgsel giver den særskilte Job Loss Type for værdierne skrevet på ADDCOLUMNS .
Ved at bruge Eager Evaluation får du alt i én enkelt datacache. Dataene evalueres og itereres også på formelmotoren. IF - erklæringen returnerer enten det samlede skøn eller bruttofortjenesten afhængigt af den sande eller falske evaluering.
Ivrig evaluering er ikke altid den bedste metode til at optimere dine koder. Strenge evaluering vil resultere i en bedre ydeevne, hvis du har komplekse koder. Det hele afhænger af de funktioner, du bruger inde i DAX-koden.
Ulempen ved Eager Evaluation er, at hvis du opretter værdigenstande før en IF- eller SWITCH- sætning og bruger de variable inde i sætningen, som aldrig bør udføres, vil motoren stadig beregne disse variable.
Her er et eksempel på ulempen:
Ideelt set, hvis jobtabstypen er lig med A, bør den få bruttofortjeneste. Ellers får den Total Estimat.
Da der ikke er nogen værdi i kolonnen Jobtabstype, der er lig med A, bør den altid få samlet skøn. Det giver dog stadig bruttofortjenesten i datacachen.
Hvis du ser på den første forespørgsel, får den Jobtabstypen og summen af Jobs Bruttofortjeneste og Estimat.
I den næste forespørgsel får den en særskilt jobtabstype fra jobtabellen.
3. Metode: IF.EAGER Evaluering
Den næste metode er IF.EAGER- funktionsevalueringen, som gentager adfærden fra Eager Evaluation.
Det lader dig skrive en kode, der repræsenterer den strenge evaluering og udføre den med Ivrig evaluering.
Hvis du ser på denne eksempelkode, er den bare den samme som Strict Evaluation-koden. Den eneste forskel er, at dette bruger IF.EAGER- funktionen i stedet for IF .
Før du udfører koden, skal du sørge for at oprette forbindelse til LuckyTemplates-modellen og slå Server Timing til. Når du er færdig, skal du trykke på F5.
Du kan se, at det genererede 3 lagringsmotorforespørgsler.
Den første forespørgsel får jobtabstypen og summen af jobestimatet og bruttofortjenesten.
Den anden forespørgsel får summen af jobestimatet.
Den sidste forespørgsel får den særskilte jobtabstype fra jobtabellen.
Du vil bemærke, at den udførte den samme adfærd som Eager Evaluation.
Opsummering af evalueringsmetoder
I forsøget på at forbedre ydeevnen af dine beregninger, skal du huske følgende:
Men vær opmærksom på, at du skal teste disse tre metoder for at finde ud af, hvad der virkelig er bedst at bruge i din rapport.
4. Optimer et mål i LuckyTemplates
Den vigtigste lektion i denne øvelse er at optimere dine koder.
Gå tilbage og se på RB Incentive% -målet, der udføres ved hjælp af Strict Evaluation. Prøv derefter at evaluere det ved hjælp af Eager Evaluation.
Start med at oprette variabler og indtaste RETURN -funktionen.
Skift målreferencerne med variablerne.
Bekræft derefter målingen og gå til DAX Studio for at se, om det forbedrede ydeevnen.
Den viser, at den samlede tid er 642 millisekunder, og det samlede antal forespørgsler i lagermotoren er blevet reduceret til 39.
Opret nu variablerne for alle data og skift alle målereferencer til deres tilsvarende variable.
Bekræft derefter målingen og kør koden i DAX-studiet.
Den samlede eksekveringstid og den samlede mængde af storage engine-forespørgsler er blevet reduceret fra henholdsvis 600 millisekunder til 170 millisekunder og 43 forespørgsler til 15 forespørgsler.
Du kan også se, at der ikke er nogen dubletter. At have variabler i din kode forbedrer deres læsbarhed og ydeevne.
Avanceret optimering til et mål i LuckyTemplates
Dernæst skal du optimere dine DAX-koder yderligere.
I stedet for at bruge, brug fungere.
HASONEVALUE tæller antallet af tilgængelige værdier i filterkonteksten, hvilket er en meget intensiv operation. I mellemtiden kontrollerer ISINSCOPE , om den kolonne, der leveres, bruges til gruppering eller ej.
Efter at have ændret funktionerne, skal du bekræfte målingen og udføre den i DAX Studio.
Du kan se, at antallet af storage engine-forespørgsler nu er 12. Den samlede eksekveringstid er også blevet 105 millisekunder.
I den 2. forespørgsel vil du bemærke et tilbagekaldsdata-id.
Dette sker nogle gange, når du bruger SELECTEDVALUE med tekstfeltet. Når du ser tilbagekaldsdata, kalder lagermotoren formelmotoren for at hjælpe med at løse kodens kompleksitet. Dette sænker ydeevnen af din foranstaltning.
Du skal fjerne tilbagekaldsdataene for at få en bedre ydeevne i din rapport. For at gøre det skal du oprette en konfigurationstabel i datamodellen.
Gå til Indtast data og indsæt dataene. Navngiv tabellen LossTypeConfigTable .
Klik derefter på Rediger for at ændre datatypen for den kolonne, du vil importere.
Datatypen for tabstype-id'et skal være en lærerværdi, så den kan bruges i funktionen SELECTEDVALUE .
Når den er blevet indlæst i modellen, skal du oprette en relation mellem tabellen Jobs og tabellen LossTypeConfigTable baseret på tabstypen.
Når du har oprettet en relation, skal du gå til tabellen Jobs og tilføje en ny kolonne. Kald det Loss ID, og indtast derefter formlen.
Brug funktion for konfigurationstabellen og udtræk derefter tabstype-id'et.
Gå derefter tilbage til RB Incentive%-målet og referer til det numeriske felt i stedet for tekstfeltet. Inde i SELECTEDVALUE skal du erstatte tabstype med tabs-id.
Derefter skal du ændre alle målene i koden. Brug en heltalsværdi i stedet for tekstværdier, når du tjekker for jobtypen.
Når du har ændret koden, skal du bekræfte målingen og udføre den i DAX Studio.
Callback-data-id'et elimineres i forespørgslen, og kodens eksekveringstid reduceres til 93 millisekunder.
RB Incentive%-målet er nu fuldt optimeret.
5. Optimer andre tiltag i LuckyTemplates
Du skal også optimere målene WR Incentive% og QB Incentive%.
Kopiér og indsæt den nøjagtige kode, der bruges i RB Incentive%-målet. Kør derefter de 3 takter sammen.
Den samlede udførelsestid er optimeret og reduceret fra 1855 millisekunder til 213 millisekunder. Der er også kun 12 lagringsmotorforespørgsler.
De første to forespørgsler skaber filterkonteksten, og resten repræsenterer det nøjagtige antal værdier i kolonnen Jobtabstype.
Da alle mål er blevet optimeret, skal du køre den originale kode og se, hvordan ydeevnen har ændret sig. Dataene viser, at det nu bliver beregnet på 1,9 sekunder.
Ydeevnen af hele koden er nu optimeret, hvilket gør din rapport hurtigere og bedre.
Konklusion
I LuckyTemplates-rapporter bør foranstaltninger optimeres for at sikre, at dine DAX-koder kører problemfrit. Dette forbedrer også den overordnede ydeevne af din rapport.
Du har lært de forskellige metoder til at optimere dit mål i LuckyTemplates, og du har lært, hvordan du vurderer, hvilken du skal bruge afhængigt af konteksten for din rapport.
Denne blog indeholder LuckyTemplates TOPN DAX-funktionen, som giver dig mulighed for at få unik indsigt fra dine data, hvilket hjælper dig med at træffe bedre markedsføringsbeslutninger.
Find ud af, hvorfor det er vigtigt at have en dedikeret datotabel i LuckyTemplates, og lær den hurtigste og mest effektive måde at gøre det på.
Denne korte vejledning fremhæver LuckyTemplates mobilrapporteringsfunktion. Jeg vil vise dig, hvordan du kan udvikle rapporter effektivt til mobilenheder.
I denne LuckyTemplates Showcase gennemgår vi rapporter, der viser professionel serviceanalyse fra et firma, der har flere kontrakter og kundeengagementer.
Gå gennem de vigtigste opdateringer til Power Apps og Power Automate og deres fordele og implikationer for Microsoft Power Platform.
Opdag nogle almindelige SQL-funktioner, som vi kan bruge, såsom streng, dato og nogle avancerede funktioner til at behandle eller manipulere data.
I denne tutorial lærer du, hvordan du opretter din perfekte LuckyTemplates-skabelon, der er konfigureret til dine behov og præferencer.
I denne blog vil vi demonstrere, hvordan man lagdelte feltparametre med små multipler for at skabe utrolig nyttig indsigt og visuals.
I denne blog vil du lære, hvordan du bruger LuckyTemplates rangerings- og brugerdefinerede grupperingsfunktioner til at segmentere et eksempeldata og rangordne det efter kriterier.
I denne tutorial vil jeg dække en specifik teknik omkring, hvordan du kun viser Kumulativ Total op til en bestemt dato i dine visuals i LuckyTemplates.
