Optimera applikationsprestanda

Applikationens prestanda kan förbättras med minskad applikationsstorlek, förenklade datamodeller och strategisk användning av set-analys. Det här delavsnittet hjälper dig att undvika prestandaproblem genom att peka ut områden där prestandan kan påverkas och hur du kan utvärdera och övervaka applikationsprestanda.

Du kan övervaka din applikations prestanda med hjälp av verktyget för prestandautvärdering, och du kan även testa hur den presterar på olika motorstorlekar genom att manuellt tilldela större motorer. Mer information finns i Utvärdering av applikationsprestanda och Tilldela motorer för att förbättra applikationens prestanda.

Applikationskomplexitet

Dessa är lösa kategorier som kan hjälpa till att diagnostisera problem. De mest komplexa applikationerna har lägst prestanda.

Enkla applikationer:

Innehåller inte komplex set-analys eller If()-satser.
Innehåller inte stora tabeller.
Har en enkel datamodell.
Innehåller enkla beräkningar.
Kan ha stora datavolymer.

Måttliga applikationer:

Har en datamodell med många tabeller, men följer bästa praxis.
Använder set-analys och flera If()-satser.
Har stora eller breda tabeller på ark (15 kolumner eller fler).

Komplexa applikationer:

Har en mycket komplex datamodell.
Ansluter till stora datavolymer.
Innehåller komplexa beräkningar, diagram och tabeller.

Stora datavolymer

Du kan använda dessa arkitekturstrategier när du ansluter till stora datavolymer.

Segmentering

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

En QVD som innehåller data från de två senaste åren.
En QVD som innehåller historiska data äldre än två år.
En QVD som innehåller alla data aggregerade på en högre nivå. Till exempel per månad i stället för datum, eller per land i stället för enskilda kunder.
En stor QVD med alla data, som endast används av en liten delmängd användare.

Du kan segmentera applikationerna på ett liknande sätt. Mindre applikationer kommer att tillgodose de flesta användares analysbehov. Detta sparar minne.

Du kan också ha flera applikationer inriktade på olika regioner. På så sätt öppnar användarna inte en applikation med data som de inte är intresserade av eller inte har behörighet till. Data som inte är tillgängliga via section access påverkar fortfarande minnet.

On-Demand Application Generation (ODAG)

Qlik Sense on-demand-applikationer ger användare aggregerade vyer av stora datalager. De kan identifiera och ladda relevanta delmängder av data för detaljerad analys.

Ur ett användarperspektiv finns det två applikationer:

En kundvagn med aggregerade data.
En tom mallapplikation som används för att visa detaljer.

Användaren gör urval i kundvagnsapplikationen. När en tröskel har uppnåtts skapas ett anpassat LOAD-skript som fyller mallapplikationen med de begärda detaljerna. Mer information finns i Hantera stora datamängder med on-demand-applikationer.

Applikationskedjning

Applikationskedjning (känt som dokumentkedjning i QlikView) innebär att det finns en aggregerad applikation som användare konsumerar regelbundet. Om en användare behöver mer detaljer kan urval skickas från den aggregerade applikationen till en detaljapplikation, så att de kan se en lägre detaljnivå. Detta sparar minne, eftersom användare inte laddar onödiga detaljer. Applikationskedjning kan utföras genom att lägga till knappobjekt på ett ark. Mer information finns i Programkedja.

Applikationskedjning stöds också via APIs. Till exempel kan du använda Appintegrations-API för att skapa anpassad applikationskedjning. Mer information finns i Appintegrations-API (endast på engelska).

Dynamiska vyer

Dynamiska vyer möjliggör aktuella visualiseringar för scenarier med stora datavolymer eller snabbt föränderliga data. Tänk på följande när du arbetar med dynamiska vyer:

När du uppdaterar dynamiska vyer laddas datakällan direkt. Uppdateringsprestandan påverkas av prestandan hos den underliggande datakällan.
Mallapplikationer för dynamiska vyer kan hjälpa dig att skapa dynamiska diagram.

Mer information om hur du använder dynamiska vyer finns i Hantera data med dynamiska vyer.

Direct Query

Även om in-memory-applikationer rekommenderas, låter Direct Query dig behålla data i dess ursprungliga källa. Tänk på följande för att optimera din användning av Direct Query:

Prestandan för Direct Query påverkas kraftigt av prestandan hos den underliggande datakällan.
Håll din Direct Query-datamodell så enkel som möjligt, eftersom komplexa frågor kan orsaka prestandaproblem.

Mer information om Direct Query finns i Komma åt molndatabaser direkt med Direct Query.

Datamodellsprestanda

Följande är faktorer som kan påverka datamodellens prestanda. Var och en är en rekommenderad metod som förbättrar applikationens användbarhet.

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 lösas, 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 din applikation ansluter till en stor mängd data från databaser som uppdateras fortlöpande kan det ta lång tid att ladda om 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 här: Kombinera tabeller med Join och Keep.
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 faktiskt används i applikationen.
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. Dessa mindre månatliga QVD kan sedan stödja många olika applikationer som kanske inte behöver alla data.

Arkprestanda

Dessa är bästa praxis som kommer att förbättra prestandan för ark och visualiseringar.

Bästa praxis för arkprestanda
Åtgärd	Beskrivning
If()-funktionen undviks där det är möjligt	Om If()-funktionen används inuti en aggregeringsfunktion kommer den att fungera på postnivå och utvärderas många gånger. Om du till exempel har 1 000 poster i en aggregering kommer ett If()-villkor att utvärderas 1 000 gånger. Detta kan snabbt kaskadera om du nästlar satser. Du bör använda set-analys i stället. Ett set-analysfilter tillämpas före aggregeringen, vilket resulterar i ett snabbare svar. Dessa svar kan också cachas via set-analys, vilket If() inte kan. Du kan också överväga andra funktioner och ändringar i datamodellen.
Fält från olika tabeller inuti en aggregeringstabell undviks där det är möjligt.	När en aggregering utvärderas går beräkningen igenom två steg: Det första steget är att hitta de relevanta kombinationerna som beräkningen ska göras på. Detta steg är entrådigt. Det andra steget är att utföra beräkningen. Detta steg är flertrådigt. Den entrådiga delen kan påverka prestandan avsevärt. Ett exempel är om du har flera fält inuti aggregeringen, till exempel Sum(Quantity*ListPrice). Om Quantity finns i faktatabellen, och ListPrice finns i huvudprodukttabellen, måste motorn först slå samman de två tabellerna för att hitta kombinationerna innan den kan börja summera produkten. Sammanslagningen är den entrådiga delen, och summeringen är flertrådig. Om båda fälten finns i samma tabell behövs ingen sammanslagning, och aggregeringen utvärderas avsevärt snabbare.
Aggr() och nästlade Aggr()-funktioner används minimalt	Aggr()-funktionen påverkar prestandan kraftigt. Felaktig användning kan ge felaktiga resultat. Till exempel i en tabell med dimensioner som skiljer sig från dimensionerna inuti Aggr()-funktionen. Mer information finns i When should AGGR not be used?
Set-analys används där det är möjligt	Du kan använda set-analys för att definiera en uppsättning datavärden som skiljer sig från den normala uppsättningen som definieras av de aktuella urvalen. Mer information finns i Set-analys.
Strängjämförelser undviks där det är möjligt	Strängjämförelser är inte lika effektiva som set-analys. Till exempel bör du undvika Match(), MixMatch(), WildMatch() och Pick(). Skapa flaggor i skriptet eller använd set-analys i stället. Mer information finns i Villkorsfunktioner och Performance of conditional aggregations.
Beräkningsvillkor används på objekt som innehåller intensiva beräkningar	Du kan ha visualiseringar med många poster när det inte finns några urval. Som bästa praxis bör du lägga till beräkningsvillkor på objekt så att de endast renderas efter att vissa urval har gjorts. Detta stoppar skapandet av mycket stora hyperkuber. Till exempel: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. I det här scenariot kommer visualiseringen inte att renderas om inte användaren väljer ett enda land, eller gör andra urval där endast ett enda land är möjligt.
Mått förberäknas i skriptet där det är möjligt	Alla mått som är på den lägsta detaljnivån i datamodellen bör beräknas i skriptet. Om du till exempel i samma post i en tabell har Sales och Cost, kan du härleda 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 som ä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 på tabellobjektet så att det endast renderas efter att vissa urval eller kriterier har uppfyllts. Om din tabell är mycket bred, överväg att: Skapa flera mindre tabeller som visas villkorligt. Använda metoder för att villkorligt visa kolumner. Hålla dina tabeller begränsade till endast de fält som är nödvändiga för din analys.
Ark har inte ett överdrivet antal objekt	Objekt beräknas när användaren navigerar till arket. Varje gång en användare gör ett urval på det arket kommer varje objekt att omberäknas om det aktuella tillståndet inte finns i cachen. Om du har ett ark med många diagram kommer användaren att behöva vänta på att varje objekt beräknas vid nästan varje urval. Detta lägger en betydande belastning på motorn. Som bästa praxis, följ Dashboard/Analysis/Reporting (DAR) -konceptet för att utveckla en ren och minimal applikation. Mer information finns i DAR methodology.
Numeriska flaggor utnyttjas 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.
Huvudobjekt eller variabler används för uttryck	Huvudobjekt möjliggör dra och släpp av styrda mätvärden och garanterar att uttryck cachas. Till exempel skiljer sig Sum(Sales) från SUM(Sales). Uttryck cachas baserat på stavning och skiftläge, och måste matcha ordagrant för att kunna återanvändas.

Dataladdningsprestanda

Att optimera dataladdning är viktigt för en sömlös och responsiv upplevelse när du arbetar med applikationer i Qlik Cloud. Det här delavsnittet belyser prestandapåverkande faktorer och ger vägledning om hur du förhindrar prestandaproblem.

Qlik Data Gateway – direktåtkomst

När du använder Qlik Data Gateway – direktåtkomst för att ladda om data till din applikation påverkar följande faktorer prestandan:

Kopplingshastighet och latens mellan maskinen som är värd för Data Gateway och databasen.
Kopplingshastighet och latens mellan maskinen som är värd för Data Gateway och din Qlik Cloud-klientorganisation. Helst bör du vara värd för Data Gateway i samma region som din Qlik Cloud-klientorganisation för förbättrad prestanda.

Databaslagring

Långsamma lagringskopplingar kan öka omladdningstiderna. Tänk på följande för databaser som är värdbaserade lokalt eller i molnet:

Lokalt: Om din databas är lokal och delar en server med andra applikationer kan dess prestanda påverkas av aktiviteterna i dessa andra applikationer.
Moln: När de är korrekt dimensionerade erbjuder molndatabaser vanligtvis bättre prestanda än lokala databaser. För optimala resultat, välj en region för din molnlagring som ligger nära din Qlik Cloud-klientorganisation.

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

Om du stöter på några problem med den här sidan eller innehållet på den, t.ex. ett stavfel, ett saknat steg eller ett tekniskt fel – meddela oss!

Lämna din feedback här