Mät i LuckyTemplates: Optimeringstips och tekniker

I den här handledningen får du lära dig hur du optimerar ett mått i LuckyTemplates. Att optimera åtgärder i din rapport förbättrar prestandan för dina koder när det gäller att producera värdefulla insikter och data. Du kommer också att lära dig om de olika utvärderingsmetoderna och hur du använder dem för att optimera din rapport. Du kan se hela videon av denna handledning längst ner på den här bloggen.

Innehållsförteckning

• 1. Analysera kodens prestanda
  • Variabler i måttet
  • Kall cache för DAX Studio
• 2. Analysera ett mått i LuckyTemplates
  • RB Incentive%-måttet i LuckyTemplates
    • Data från lagringsmotorn
  • Logiken bakom IF och Switch
• 3. Använd kodutvärderingsmetoder
  • Första metoden: Strikt utvärdering
  • 2:a metoden: Ivrig utvärdering
    • Ivrig utvärdering Nackdelar
  • 3:e metod: IF.EAGER-utvärdering
  • Sammanfattning av utvärderingsmetoder
• 4. Optimera ett mått i LuckyTemplates
  • Avancerad optimering för en åtgärd i LuckyTemplates
    • Ta bort återuppringningsdata
• 5. Optimera andra åtgärder i LuckyTemplates
• Slutsats

1. Analysera kodens prestanda

I det här exemplet måste du optimera den här rapporten:

Det här är datamodellen du ska använda:

Tabellen Jobb innehåller all information om alla jobb som har utförts under en viss tidsperiod.

Den här tabellen är basen för alla åtgärder som du ska optimera:

Först måste du testa rapportens prestanda.

Gå till fliken Visa och välj. Klicka sedan på Starta inspelning och uppdatera bilder . Vänta tills analysatorn återger det visuella.

När detta är gjort, rulla ned listan Incitament Breakdown och klicka på Kopiera fråga .

Välj sedan Externa verktyg för att gå till DAX Studio och titta på koden som LuckyTemplates genererade.

Klistra sedan in den kopierade frågan i arbetsytan.

Variabler i måttet

Den första variabeln är DateClosed som är skivaren på instrumentpanelen. Den använder en kolumn från faktatabellen för att få värdena för vissa perioder i slicern.

Nästa variabel är JobLost som söker efter False eller Blank av Job Lost-data.

Den sista variabeln är MatrixVisual . Detta är hjärtat i koden. Den visar den sammanfattade kolumnen som genereras av LuckyTemplates för att fylla i matrisbilder. Den grupperar Job Loss Type i denna matris och injicerar filtren som kommer från skärmaskinerna. Sedan lägger den till utökade kolumner.

När sammanfattningskolumnen har slutfört körningen kommer du att se resultaten i rutan under koden.

LuckyTemplates använder resultatet för att fylla i matrisbilder.

Kall cache för DAX Studio

Därefter måste du kontrollera tiden det tar att köra hela koden. För att göra det, slå på Server Timings och välj sedan Rensa cache och kör sedan .

När du försöker optimera ett mått i LuckyTemplates med hjälp av, det är bättre att arbeta under scenariot med kall cache så att tiden du får är korrekt. Därefter trycker du på F5 och väntar på att operationen är klar på fliken Server Timings .

När den är klar kan du se att den totala körningstiden är 3,6 sekunder. Den tillbringade större delen av tiden i formelmotorn och tillbringade 57 millisekunder i lagringsmotorn

Du kan också se att den hittade 383 lagringsmotorfrågor. Av alla dessa frågor finns det 327 som är castade i minnet så att de kan återanvändas.

2. Analysera ett mått i LuckyTemplates

Därefter måste du optimera dessa 3 identiska åtgärder.

Du måste extrahera dessa åtgärder i en annan fil och koppla den till datamodellen du använder.

Efter det startar du Server Timings för att se hur lång tid de tre åtgärderna tar för att fylla i bilder.

Resultatet av körningen visar att åtgärderna tar 1,85 sekunder för att hämta ett resultat.

Resultatet visar en tabell bestående av 10 rader och 3 utökade kolumner som hör hemma i de sammanfattade kolumnerna.

Kolumnen Förlusttyp innehåller 10 unika värden som koden beräknar för att få incitamentsprocenten.

Tiden som koden tar är exponentiellt hög. Det är här och när du behöver optimera dem.

RB Incentive%-måttet i LuckyTemplates

Detta är ett RB Incentive%-mått i LuckyTemplates. Det är ett av de tre huvudmåtten som används i det här exemplet.

Du kan se att den försöker beräkna incitamentsprocenten.

Den har en variabel, JobType, som hämtar Lost Type-värdet i den aktuella filterkontexten. Den kontrollerar också om det bara finns ett enda värde som är synligt i det aktuella filterkontexten. Du måste använda en  funktion så att varje gång ett villkor uppfylls ger det motsvarande resultat.

Denna åtgärdskod genererar mycket lagringsmotorfett vilket ökar tiden i kodens totala varaktighet.

Gå nu tillbaka till DAX Studio för att kontrollera mängden lagringsmotorfrågor som måttet genererar.

Du kan se att det tog 600 millisekunder att köra och 43 lagringsmotorfrågor för att helt enkelt hämta data för de 10 raderna.

Data från lagringsmotorn

Kontrollera nu de data som efterfrågas från lagringsmotorn. I den första frågan finns en Jobbförlusttyp och DCOUNT  av Jobbförlusttypen.

Nästa fråga har Jobs Date Closed som kommer från slicern i rapporten.

I den tredje koden ser du en annan typ av jobbförlust med återuppringningsdata-ID.

På en annan rad ser du de viktigaste kodraderna.

Det första du ser är betalningen mottagna, fakturerade och faktiska utgifter för jobb.

Nästa är WHERE  -funktionen som anger ett villkor och dess motsvarande resultat. Resultatet kommer att variera baserat på valet av slicer och switch-satsen i RB Incentive%-måttet.

Du kommer också att märka att koden på rad 12 och 14 är densamma.

Om du scrollar åt höger kan du se att det finns rader med samma frågor. Frågorna på raderna styrs av switch-satsen i RB Incentive%-måttet.

Om du går tillbaka till RB Incentive%-måttet i LuckyTemplates kan du se hur många gånger en fråga upprepas och hur det återspeglas i lagringsmotorfrågorna.

Logiken bakom IF och Switch

Nu, för att förstå varför frågorna körs flera gånger, måste du förstå logiken i och SWITCH- funktioner.

Du måste utföra dem separat på en frågeplan. Men innan du gör det, se till att ansluta till databasen och aktivera frågeplanen.

Kör SWITCH-  satsen i frågeplanen. Markera sedan  uttalandet och tryck sedan på enter.

Detta kommer att generera en logisk frågeplan med olika operationer.

Kör sedan IF- satsen genom att markera satsen och trycka på enter.

Du kan se att den genererar samma logiska frågeplan.

Detta beror på att när du använder en , konverterar motorn internt den funktionen till en IF- sats. Men en SWITCH -sats rekommenderas eftersom den ökar läsbarheten för din kod.

Efter det måste du förstå hur en kod exekveras i IF- eller SWITCH -funktionen.

Detta är en exempelkod som har en SWITCH -sats inuti.

Den har mått för bruttovinst, total uppskattning och total fakturering som alla är SUMMA för olika kolumner. Den har också en funktion över Jobs Loss Type och en SWITCH och TRUE -sats.

När du kör den här koden ser du logiken bakom funktionerna.

Den första frågan får den distinkta Jobs Loss Type från tabellen Jobs.

Förutom jobbförlusttypen får den också summan av jobbuppskattningen.

Inuti WHERE- villkoret kan du också se de värden som finns i kolumnen Jobbförlusttyp.

3. Använd kodutvärderingsmetoder

I DAX finns det tre metoder för att utvärdera koder:

• Strikt utvärdering
• Ivrig utvärdering
• IF.Eager utvärdering

Dessa metoder hjälper dig att optimera en kod eller ett mått i LuckyTemplates.

Första metoden: Strikt utvärdering

I exemplet nedan används strikt utvärderingsmetoden.

Logiken bakom det är att om sammanhanget för arbetsförlusttypen är lika med A, kommer det att ge bruttovinsten. Annars ger det den totala uppskattningen. Koden gör detta för varje rad i Jobs Loss Type.

Detta är ytterligare ett exempel på mått i LuckyTemplates som använder strikt utvärdering.

När du kör den här koden kommer den att generera 5 lagringsmotorfrågor.

Med strikt utvärdering ger koden den totala uppskattningen om bruttovinsten multiplicerad med 1,4 är större än den genomsnittliga uppskattningen. Annars kommer det att ge Bruttovinsten.

Att använda strikt utvärdering producerar fler lagringsmotorfrågor eftersom IF  -satsen kontrollerar bruttovinstens konkurrens flera gånger och så småningom kommer att försvåra prestanda för hela operationen.

2:a metoden: Ivrig utvärdering

Detta är samma kod som föregående exempel.

Men istället för att beräkna måtten inuti  IF- satsen, beräknade den allt i före RETURN .

Det betyder att innan du kontrollerar påståendena får den alla värden för bruttovinsten och totaluppskattningen för alla typer av jobbförluster.

När du kör den här koden reduceras antalet lagringsmotorer till 3.

Det förbättrar prestandan för hela operationen.

I den första operationsfrågan får den typen av jobbförlust och summan av jobbuppskattning och bruttovinst.

Nästa fråga får summan av jobbuppskattningen från jobbstallet. Detta används för att beräkna medeluppskattningen.

Den sista frågan ger den distinkta Jobs Loss Type för värdena som skrivs på ADDCOLUMNS .

Genom att använda Eager Evaluation får du allt i en enda datacache. Data utvärderas och itereras också på formelmotorn. IF -  utlåtandet kommer att returnera antingen den totala uppskattningen eller bruttovinsten beroende på den sanna eller falska utvärderingen.

Eager Evaluation är inte alltid den bästa metoden för att optimera dina koder. Strikt utvärdering kommer att resultera i bättre prestanda om du har komplexa koder. Allt beror på vilka funktioner du använder i DAX-koden.

Nackdelen med Eager Evaluation är att om du skapar värdesaker före en IF-  eller  SWITCH  -sats och använder de variabler inuti satsen som aldrig ska köras, kommer motorn fortfarande att beräkna dessa variabler.

Ivrig utvärdering Nackdelar

Här är ett exempel på nackdelen:

Helst, om Jobs Loss Type är lika med A bör den få bruttovinst. Annars får den Total Estimate.

Eftersom det inte finns något värde i kolumnen Jobbförlusttyp som är lika med A, bör den alltid få total uppskattning. Det ger dock fortfarande bruttovinsten i datacachen.

Om du tittar på den första frågan får den typen av jobbförlust och summan av bruttovinsten och uppskattningen för jobb.

I nästa fråga får den en distinkt jobbförlusttyp från tabellen jobb.

3:e metod: IF.EAGER-utvärdering

Nästa metod är  IF.EAGER-  funktionsutvärderingen som replikerar beteendet hos Eager Evaluation.

Den låter dig skriva en kod som representerar den strikta utvärderingen och exekvera den med Eager Evaluation.

Om du tittar på den här exempelkoden är den precis samma som koden för strikt utvärdering. Den enda skillnaden är att detta använder IF.EAGER  -funktionen istället för IF .

Innan du kör koden, se till att ansluta till LuckyTemplates-modellen och slå på Server Timing. När du är klar trycker du på F5.

Du kan se att det genererade 3 lagringsmotorfrågor.

Den första frågan får typen av jobbförlust och summan av jobbuppskattningen och bruttovinsten.

Den andra frågan får summan av jobbuppskattningen.

Den sista frågan får den distinkta typen av jobbförlust från tabellen jobb.

Du kommer att märka att den utförde samma beteende som Eager Evaluation.

Sammanfattning av utvärderingsmetoder

När du försöker göra dina beräkningar bättre måste du komma ihåg följande:

• Strikt utvärdering används för komplexa koder. Det gäller även när du inte vill utvärdera alla värden som anges i tabellen.
• Eager Evaluation är bättre att använda om dina koder är enkla.
• Använd IF.EAGER om du vill skriva koder med Strict Evaluation och exekvera det med Eager Evaluation.

Men notera att du måste testa dessa tre metoder för att ta reda på vad som verkligen är bäst att använda i din rapport.

4. Optimera ett mått i LuckyTemplates

Huvudläxan i denna handledning är att optimera dina koder.

Gå tillbaka och titta på RB Incentive% -måttet som exekveras med strikt utvärdering. Prova sedan att utvärdera det med Eager Evaluation.

Börja med att skapa variabler och mata in  RETURN -funktionen.

Ändra måttens referenser med variablerna.

Efter det, bekräfta måttet och gå till DAX Studio för att se om det förbättrade prestandan.

Den visar att den totala tiden är 642 millisekunder och det totala antalet lagringsmotorfrågor har reducerats till 39.

Skapa nu variablerna för all data och ändra alla mätreferenser till deras motsvarande variabler.

Bekräfta sedan måttet och exekvera koden i DAX-studion.

Den totala exekveringstiden och det totala antalet lagringsmotorfrågor har reducerats från 600 millisekunder till 170 millisekunder respektive 43 frågor till 15 frågor.

Du kan också se att det inte finns några dubbletter. Att ha variabler i din kod förbättrar deras läsbarhet och prestanda.

Avancerad optimering för en åtgärd i LuckyTemplates

Därefter måste du optimera dina DAX-koder ytterligare.

Istället för att använda, använda sig av fungera.

HASONEVALUE  räknar antalet tillgängliga värden i filterkontexten, vilket är en mycket intensiv operation. Samtidigt kontrollerar ISINSCOPE om kolumnen som levereras används för gruppering eller inte.

Efter att ha ändrat funktionerna, bekräfta mätningen och kör den i DAX Studio.

Du kan se att antalet lagringsmotorfrågor nu är 12. Den totala exekveringstiden har också blivit 105 millisekunder.

I den andra frågan kommer du att märka ett återuppringningsdata-ID.

Detta händer ibland när du använder SELECTEDVALUE med textfältet. När du ser återuppringningsdata anropar lagringsmotorn formelmotorn för att hjälpa till att lösa kodens komplexitet. Detta saktar ner prestandan för din åtgärd.

Ta bort återuppringningsdata

Du måste ta bort Callback-data för att få bättre resultat i din rapport. För att göra det måste du skapa en konfigurationstabell i datamodellen.

Gå till alternativet Ange data och klistra in data. Namnge tabellen LossTypeConfigTable .

Klicka sedan på Redigera för att ändra datatypen för kolumnen som du ska importera.

Datatypen för förlusttyps-ID bör vara ett lärarvärde så att det kan användas i funktionen SELECTEDVALUE .

När den har laddats in i modellen skapar du en relation mellan tabellen Jobb och tabellen LossTypeConfigTable baserat på förlusttypen.

När du har skapat en relation, gå till tabellen Jobb och lägg till en ny kolumn. Kalla det förlust-ID och skriv sedan in formeln.

Använd funktion för konfigurationstabellen och extrahera sedan förlusttyp-ID.

Gå sedan tillbaka till RB Incentive%-måttet och referera till det numeriska fältet istället för textfältet. Inuti SELECTEDVALUE , ersätt förlusttyp med förlust-ID.

Ändra sedan alla mått i koden. Använd ett heltalsvärde istället för textvärden när du söker efter jobbtyp.

När du har ändrat koden, bekräfta måttet och kör det i DAX Studio.

Callback-data-ID:t elimineras i frågan och kodens exekveringstid reduceras till 93 millisekunder.

RB Incentive%-måttet är nu helt optimerat.

5. Optimera andra åtgärder i LuckyTemplates

Du måste också optimera måtten WR Incentive% och QB Incentive%.

Kopiera och klistra in den exakta koden som används i RB Incentive%-måttet. Kör sedan de 3 måtten tillsammans.

The total execution time is optimized and reduced from 1855 milliseconds to 213 milliseconds. There are also only 12 storage engine queries.

The first two queries create the filter context and the rest represent the exact number of values inside the Jobs Loss Type column.

Since all measures have been optimized, run the original code and see how the performance has changed. The data shows that it’s now being computed in 1.9 seconds.

The performance of the whole code is now optimized, making your report faster and better.

Conclusion

In LuckyTemplates reports, measures should be optimized to ensure that your DAX codes run smoothly. This also improves the overall performance of your report.

You’ve learned the different methods to optimize your measure in LuckyTemplates and you’ve learned how to assess which one to use depending on the context of your report.