Optimera appens prestanda

Du kan förbättra appens prestanda genom att minska dess storlek, använda enklare datamodeller och genom strategisk användning av set-analys. I det här avsnittet beskrivs vilka områden som kan påverka prestandan så att du kan undvika prestandaproblem, och hur du kan utvärdera och övervaka appens prestanda.

Appens komplexitet

Här följer några kategorier som kan hjälpa dig att diagnostisera problem. De mest komplexa apparna har sämst prestanda.

Enkla appar:

innehåller inte komplexa set-analys- eller If()-satser
innehåller inte stora tabeller
har en enkel datamodell
innehåller enkla beräkningar
kan använda stora datavolymer.

Medelkomplexa appar:

har en datamodell med många tabeller, men är uppbyggda enligt bästa praxis
använder set-analys och flera If()-satser
har stora och breda tabeller på ark (15 kolumner och uppåt).

Komplexa appar:

har en mycket komplex datamodell
ansluter till stora datavolymer
innehåller komplexa beräkningar, diagram och tabeller.

Appdetaljer

Du måste fundera på appstorlek i förhållande till maskinvarumiljön, eftersom detta påverkar Qlik Sense-driftsättningens prestanda. Om du exempelvis inte optimerar dina appar kan de kräva mer maskinvaruresurser.

Genom att övervaka appstorleken kan du:

förstå aktuella prestanda
förstå hur driftsättning av en ny app påverkar prestanda
förstå hur prestanda påverkas när du gör ändringar i en befintlig app
lösa prestandaproblem
planera för expansion i framtiden.

Qlik erbjuder verktyg som kan hjälpa dig att utvärdera dina appar. Mer information finns här: Prestanda och skalbarhet i Qlik Sense Enterprise (endast på engelska).

Följande är de grundläggande appelementen som kan påverka prestanda:

Appdetaljer som kan påverka prestanda
Funktioner	Beskrivning
Appens storlek på disk (MB)	Appstorleken hittar du i QMC. Gå till Appar och öppna Kolumnväljare till höger intill Åtgärder. Klicka på radiokontrollen intill Filstorlek (MB). Om du använder Qlik Sense Desktop hittar du appstorleken i Windows Explorer. Standardmappen är %USERPROFILE%\Documents\Qlik\Sense\Apps. I mappen Apps listas namn och filstorlek för alla appar.
Appens storlek i RAM-minnet (GB)	Så här kan du avgöra hur mycket plats en app tar i RAM-minnet: Starta om Qlik Sense-servern. Anteckna den aktuella RAM-användningen. Öppna Qlik Sense-appen. Notera skillnaden i RAM-minne. Om du använder Qlik Sense June 2018 eller senare kan du hitta den här siffran med App Metadata Analyzer. Mer information finns i App Metadata Analyzer (endast på engelska).
Totalt antal rader i appen (M)	Du kan använda systemfält för att beräkna totalt antal rader. Skapa en KPI med måttet Sum($Rows). Mer information finns i Systemfält.
Totalt antal fält i appen	Du kan använda systemfält för att beräkna totalt antal fält. Skapa en KPI med måttet Sum($Fields). Mer information finns i Systemfält.
Totalt antal tabeller	Du kan använda systemfält för att beräkna totalt antal tabeller. Skapa en KPI med måttet Count(DISTINCT $Table). Mer information finns i Systemfält.

Övervaka appen

I Qlik Management Console (QMC) finns appar för övervakning av systemprestanda och användning i Qlik Sense Enterprise on Windows:

Appen Operations Monitor ger information om utnyttjande av maskinvara, som serverminne och CPU-användning, aktiva användare och laddning av data. Här finns även en sammanfattning av och detaljerad information om fel, varningar och loggaktiviteter i Qlik Sense-servermiljön.
Appen License Monitor registrerar licensanvändningen och gör det lättare att se ändringar i licenstilldelningen.
Appen Log Monitor visar nästan alla tillgängliga loggdata och möjliggör trendanalys och felsökning.
Appen Sessions Monitor visar loggdata om hur appar används.
Appen Reloads Monitor visar detaljerad information om dataladdning, både från QMC och från appar som är öppna i hubben.
Appen Sense System Performance Analyzer visar Qlik Sense-prestanda i alla noder.
Appen Sense Connector Logs Analyzer visar användning av och fel för specifika Qlik-kopplingar.
Appen App Metadata Analyzer ger en översikt över alla dina Qlik Sense-appar, inklusive detaljerad information om datamodell och resursanvändning för varje app.

Mer information finns i Övervaka en Qlik Sense Enterprise on Windows-plats (endast på engelska).

Stora datavolymer

Följande arkitekturstrategier kan du använda när du ansluter till stora datavolymer.

Segmentering

Du kan segmentera QVDs efter dimensioner som tidsram, region eller aggregeringsnivå. Du kan till exempel ha

en QVD som innehåller data från de två senaste åren
en QVD som innehåller historiska data från mer än två år tillbaka
en QVD som innehåller alla data som har aggregerats på en högre nivå. Till exempel per månad istället för datum, eller per land istället för individuella kunder.
en stor QVD med alla data, som bara används av en liten grupp av användarna.

Du kan segmentera apparna på ett liknande sätt. För de flesta användare kan en mindre app tillgodose analysbehoven. Detta sparar minne.

Du kan även ha flera appar som fokuserar på olika regioner. På så sätt kommer inte användarna att öppna appar med data de inte är intresserade av eller inte har åtkomst till. Även data som inte är tillgängliga via section access påverkar minnesanvändningen.

Generera on-demand-appar (ODAG)

On-demand-appar i Qlik Sense ger användare aggregerade vyer av stora databaser. De kan identifiera och ladda relevanta underuppsättningar av data för analys på detaljnivå.

Ur användarens perspektiv finns det två appar:

en varukorg med aggregerade data
en tom mallapp som används för att visa information på detaljnivå.

Användaren gör urval i varukorgsappen. När en tröskel nås, skapas ett anpassat LOAD-skript som fyller mallappen med den begärda informationen. Mer information finns i Hantera stora datamängder med on-demand-appar.

Dokumentkedjor

Dokumentkedjor innebär att det finns en aggregerad app som används ofta av användarna. Om en användare behöver mer detaljerad information kan urval överföras från den aggregerade appen till en detaljapp, där fler detaljer kan visas. Detta sparar minne eftersom användarna inte laddar information de inte behöver. Dokumentkedjor stöds via APIs:er.

Datamodellens prestanda

Följande är faktorer som kan påverka datamodellens prestanda. De är alla rekommenderade metoder som gör appen mer användbar.

Metodtips för datamodellens prestanda
Åtgärd	Beskrivning
Ta bort syntetiska nycklar	Qlik Sense skapar syntetiska nycklar när minst två datatabeller har minst två gemensamma fält. Detta kan betyda att skriptet eller datamodellen innehåller ett fel. Om du vill läsa mer om att diagnostisera syntetiska nycklar, se Syntetiska nycklar.
Ta bort cirkelreferenser från datamodellen	Cirkelreferenser uppstår när två fält har fler än en association. Qlik Sense försöker lösa dessa genom att ändra kopplingen till en av tabellerna. Alla varningar om cirkelreferenser bör dock åtgärdas, se Förstå och lösa cirkelreferenser.
Lämplig detaljnivå för data	Du ska bara ladda nödvändiga data. Exempel: en grupp användare som bara behöver data indelade efter vecka, månad och år. Du kan antingen ladda aggregerade data, eller aggregera data inom laddningsskriptet för att spara minne. Om en användare behöver visa mer detaljerade data kan du använda ODAG eller dokumentkedjor.
Använd QVDs när detta är möjligt	En QVD-fil är en fil som innehåller en tabell med data som har exporterats från Qlik Sense. Detta filformat är optimerat för snabb datainläsning från ett skript, men det är ändå mycket kompakt. Datainläsning från en QVD-fil är vanligtvis 10–100 gånger snabbare än inläsning från andra datakällor. Mer information finns i Arbeta med QVD-filer.
QVD-filer optimeras vid laddning	QVD-filer kan läsas i två olika lägen: standard (snabbt) och optimerat (snabbare). Vilket läge som används bestäms automatiskt av skriptmotorn. Det finns vissa begränsningar för optimerade laddningar. Det går att byta namn på fält, men alla följande operationer resulterar i en standardladdning: Alla omvandlingar på de fält som laddas. Att använda en where-sats gör att Qlik Sense packar upp posterna. Använda Karta på ett fält som laddas.
Utnyttja inkrementell laddning	Om appen ansluter till stora datamängder från databaser som uppdateras fortlöpande kan det ta lång tid att ladda hela datauppsättningen. Du bör istället hämta nya eller ändrade poster från databasen med inkrementell inläsning. Mer information finns i Ladda nya och uppdaterade poster med inkrementell laddning.
Snowflake -modell konsolideras	Om du har en Snowflake-datamodell kan du i vissa fall minska antalet datatabeller genom att slå ihop vissa av dem med prefixet Join eller en annan mappning. Detta är särskilt viktigt för stora faktatabeller. En tumregel är att bara ha en stor tabell. Mer information finns i To Join or Not to Join (Använda länkning eller inte).
Denormalisera tabeller som har få fält	Om du har två tabeller med få fält kan du få bättre prestanda genom att länka dem. Mer information finns i Nästa steg inom skript.
Denormalisera leaf-tabeller med mappade laddningar	Du bör inte använda prefixet Join om du bara behöver lägga till ett fält från en tabell i en annan tabell. Du bör använda uppslagsfunktionen ApplyMap, se Don't join - use ApplyMap (Länka inte – använd ApplyMap).
Ta bort eller frikoppla tidsmarkörer från datumfält	Datumfält kan ta mycket plats om tidsmarkören ingår, eftersom strängen blir längre och antalet distinkta värden är högre. Om inte precisionen är nödvändig för analysen kan du avrunda tidsmarkören till t.ex. den närmaste timmen genom att använda Timestamp(Floor(YourTimestamp,1/24)) eller ta bort tidskomponenten helt med Date(Floor(YourTimestamp)). Om du behöver tidsmarkören kan du frikoppla den från själva datumet. Du kan använda samma Floor()-funktion och sedan skapa ett nytt fält med den extraherade tiden genom att skriva ungefär så här: Time(Frac(YourTimestamp)).
Ta bort fält som inte behövs från datamodellen	Du bör bara ladda nödvändiga fält i din datamodell. Undvik att använda Load * och SELECT. Se till att behålla: fält som krävs för analysen fält som används i appen.
Undvik länktabeller när du arbetar med stora datavolymer	Du bör använda länktabeller när detta är möjligt. Konkatenerade tabeller kan dock vara mer effektiva än länktabeller när du arbetar med stora datavolymer.
Dela upp konkatenerade dimensioner i nya fält	Du bör dela upp konkatenerade dimensioner i olika fält. Då minskar antalet unika instanser av värden i fälten. Detta fungerar på ungefär samma sätt som hur tidsmarkörer kan optimeras.
Använd AutoNumber när detta är möjligt	Du kan skapa en optimerad laddning genom att ladda data från en QVD-fil först och sedan använda AutoNumber-påståendet för att konvertera värden till symbolnycklar. Mer information finns här: AutoNumber.
Undvik dataöar	Dataöar kan vara användbara men för det mesta medför de sämre prestanda. Använd variabler om du skapar öar för urvalsvärden.
Lagra QVD:er enligt inkrementella tidsramar	Du bör lagra QVD:er i steg, till exempel varje månad. De mindre QVD:erna från varje månad kan sedan användas av många olika appar som kanske inte behöver alla data.

Arkens prestanda

Här följer metodtips som ger bättre prestanda för ark och visualiseringar.

Metodtips för arkprestanda
Åtgärd	Beskrivning
Undvik funktionen If() när detta är möjligt	Om funktionen If() används inuti en aggregeringsfunktion fungerar den på postnivå och utvärderas många gånger. Om du till exempel har en aggregering med 1 000 poster utvärderas ett If()-villkor 1 000 gånger. Om du använder nästlade satser kan detta öka mycket snabbt. Du bör använda set-analys istället. Ett set-analys-filter används före aggregeringen, vilket ger snabbare svar. Svaren kan även cachelagras med set-analys, vilket inte är möjligt med If(). Det finns även andra funktioner och ändringar av datamodellen du kan överväga.
Undvik, om möjligt, att använda fält från olika tabeller inuti en aggregeringstabell.	När en aggregering utvärderas körs beräkningen i två steg: I första steget identifieras de relevanta kombinationerna som ska beräknas. Det steget är enkeltrådigt. I andra steget görs beräkningen. Det steget är flertrådigt. Den enkeltrådiga delen kan ha stor inverkan på prestandan. Ett exempel är om du har flera fält inne i aggregeringen, till exempel Sum(Quantity*ListPrice). Om Quantity ligger i faktatabellen och ListPrice ligger i huvudprodukttabellen, måste motorn först länka de två tabellerna för att hitta kombinationerna innan den kan börja summera produkten. Länkningen är den enkeltrådiga delen och summeringen är flertrådig. Om båda fälten ligger i samma tabell behövs ingen länk, och aggregeringen utvärderas mycket snabbare.
Undvik Aggr() och nästlade Aggr()-funktioner när detta är möjligt	Funktionen Aggr() har stor påverkan på prestanda. Felaktig användning kan ge felaktiga resultat. Till exempel i en tabell med dimensioner som skiljer sig från dimensionerna i Aggr()-funktionen. Mer information finns i When should AGGR not be used? (När ska AGGR undvikas?).
Använd set-analys när detta är möjligt	Set-analys gör det möjligt att definiera en uppsättning (eller en grupp) av datavärden som är olik den normala uppsättning som definieras av aktuella urval. Mer information finns i Set-analys.
Undvik strängjämförelser när detta är möjligt	Strängjämförelser är inte lika effektiva som set-analys. Du ska till exempel undvika Match(), MixMatch(), WildMatch() och Pick(). Skapa flaggor i skriptkoden eller använd set-analys istället. Mer information finns i Villkorsfunktioner och Performance of conditional aggregations (Prestanda hos villkorsstyrda aggregeringar).
Använd beräkningsvillkor för objekt som innehåller stora beräkningar	Du kanske har visualiseringar som innehåller många poster när inga urval har gjorts. Bästa praxis är då att lägga till beräkningsvillkor för objekt så att de bara renderas efter att vissa urval har gjorts. På så sätt undviker du att mycket stora hyperkuber skapas. Till exempel: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. I det här scenariot renderas visualiseringen bara om användaren väljer ett enstaka land, eller gör andra urval om det inte går att välja ett enstaka land.
Förberäkna mått i skriptet när så är möjligt	Alla mått på den mest detaljerade nivån i datamodellen bör beräknas i skriptet. Om du till exempel har Sales och Cost i samma post i en tabell, kan du ta fram marginalen genom att beräkna Sales - Cost AS Margin. Du kan också aggregera andra värden i förväg om du vet att de inte kommer att variera baserat på urval, eller är bundna till en annan detaljnivå.
Tabeller har färre än 15 kolumner och har beräkningsvillkor	En tabell med 15 kolumner kan anses vara bred. Om dina tabeller består av många poster bör du använda beräknade villkor för tabellobjektet, så att det bara renderas efter att vissa urval har gjorts eller kriterier har uppfyllts. Om tabellen är mycket bred bör du överväga att: skapa flera mindre tabeller som visas när villkor uppfylls använda metoder som visar kolumner när vissa villkor uppfylls bara ha med fält som är nödvändiga för analysen.
Ark bör inte ha överdrivet många objekt	Objekt beräknas när användaren navigerar till arket. Varje gång en användare gör ett urval på arket beräknas varje objekt igen, om inte det aktuella tillståndet finns i cacheminnet. Om du har ett ark med många diagram måste användaren vänta medan alla objekt beräknas för nästan alla urval. Detta belastar motorn avsevärt. En bra metod för att utveckla en ren och minimal app är att följa konceptet Dashboard/Analysis/Reporting (DAR) . Mer information finns i DAR methodology (DAR-metodik).
Utnyttja numeriska flaggor i skriptet för användning i set-analys	Set-analys med flaggor kan vara mer effektivt än att använda strängjämförelser eller multiplikation.
Använd originalobjekt eller variabler för uttryck	Med originalobjekt kan du dra och släppa styrda mätetal, och de garanterar att uttryck cachelagras. Till exempel skiljer sig Sum(Sales) från SUM(Sales). Uttryck cachelagras baserat på stavning och gemener/versaler, och återanvänds bara om de matchar exakt.

Var den här sidan till hjälp för dig?

Om du hittar några fel på denna sida eller i innehållet – ett stavfel, ett steg som saknas eller ett tekniskt fel – berätta för oss så att vi kan blir bättre!

Lämna din feedback här