Optymalizacja wydajności aplikacji

Wydajność aplikacji można poprawić dzięki zmniejszeniu rozmiaru aplikacji, uproszczeniu modeli danych i strategicznemu wykorzystaniu analizy zestawów. Ta sekcja pomoże uniknąć problemów z wydajnością, wskazując obszary, które mogą negatywnie wpływać na wydajność, a także wyjaśniając, jak można oceniać i monitorować wydajność aplikacji.

Złożoność aplikacji

Są to luźne kategorie, które mogą pomóc w diagnozowaniu problemów. Najbardziej złożone aplikacje mają najniższą wydajność.

Proste aplikacje:

Nie zawierają skomplikowanych analiz zestawów ani instrukcji If().
Nie zawierają dużych tabel.
Wykorzystują prosty model danych.
Zawierają proste obliczenia.
Mogą zawierać duże ilości danych.

Umiarkowanie złożone aplikacje:

Mają model danych z wieloma tabelami, ale bazują na najlepszych praktykach.
Wykorzystują analizę zestawu i kilka instrukcji If().
Mają duże lub szerokie tabele w arkuszach (15 kolumn lub więcej).

Złożone aplikacje:

Mają bardzo skomplikowany model danych.
Łączą się z dużymi ilościami danych.
Zawierają złożone obliczenia, wykresy i tabele.

Ocenianie wydajności aplikacji

Wydajność aplikacji można ocenić, jeżeli aplikacja jest rozwijana w Qlik Sense Enterprise SaaS lub Qlik Sense Business. W ramach oceny sprawdza się czas reakcji i wykorzystanie zasobów dla wszystkich obiektów publicznych w aplikacji, aby określić, na których obiektach należy się skoncentrować podczas optymalizacji wydajności. Można także porównać wydajność różnych wersji aplikacji, aby zobaczyć wyniki oceny i efekt optymalizacji. Warto pamiętać, że wyniki są prezentowane jako wskazówki i nie mogą zagwarantować rzeczywistej wydajności postrzeganej przez użytkownika w środowiskach produkcyjnych.

Szczegóły aplikacji

W odniesieniu do wielkości aplikacji należy rozważyć środowisko sprzętowe, ponieważ ma to wpływ na wydajność wdrożenia Qlik Sense. Na przykład wskutek braku optymalizacji własnych aplikacji, mogą one wymagać więcej zasobów sprzętowych.

Monitorowanie rozmiaru aplikacji pozwala:

Poznać bieżącą wydajność.
Zrozumieć wpływ wdrożenia nowej aplikacji na wydajność.
Zrozumieć wpływ edytowania istniejącej aplikacji na wydajność.
Rozwiązywać problemy z wydajnością.
Planować przyszły rozwój.

Qlik zapewnia narzędzia, które mogą pomóc w ocenie aplikacji. Więcej informacji zawiera temat: Wydajność i skalowalność w Qlik Sense Enterprise (tylko w języku angielskim).

Są to podstawowe elementy aplikacji, które mogą mieć wpływ na wydajność:

Szczegóły aplikacji, które mogą mieć wpływ na wydajność
Funkcja	Opis
Rozmiar aplikacji na dysku (MB)	Rozmiar aplikacji można znaleźć w QMC. Przejdź do obszaru Aplikacje i otwórz Selektor kolumn po prawej stronie obok opcji Akcje. Kliknij przycisk opcji obok pozycji Rozmiar pliku (MB). W przypadku Qlik Sense Desktop rozmiar aplikacji można znaleźć w Windows Explorer. Folder domyślny to %USERPROFILE%\Documents\Qlik\Sense\Aplikacje. Folder Aplikacje zawiera listę wszystkich nazw aplikacji i rozmiarów plików.
Wielkość aplikacji w pamięci RAM (GB)	Można określić podstawowe zużycie pamięci RAM przez aplikację poprzez: Ponowne uruchomienie Qlik Sense serwera. Odnotowanie aktualnego stopnia zużycia pamięci RAM. Otworzenie aplikacji Qlik Sense. Odnotowanie różnicy w pamięci RAM. W wersji Qlik Sense z czerwca 2018 r. do znalezienia tego wskaźnika można użyć programu App Metadata Analyzer . Więcej informacji można znaleźć w temacie App Metadata Analyzer (tylko w języku angielskim).
Łączna liczba wierszy aplikacji (M)	W celu obliczenia łącznej liczby wierszy można użyć pól systemowych. Utwórz KPI z miarą Sum($Rows). Więcej informacji można znaleźć w temacie Pola systemowe.
Łączna liczba pól aplikacji	W celu obliczenia łącznej liczby pól można użyć pól systemowych. Utwórz KPI z miarą Sum($Rows). Więcej informacji można znaleźć w temacie Pola systemowe.
Łączna liczba tabel aplikacji	W celu obliczenia łącznej liczby tabel można użyć pól systemowych. Utwórz KPI z miarą Count(DISTINCT $Table). Więcej informacji można znaleźć w temacie Pola systemowe.

Monitorowanie aplikacji

Konsola zarządzania Qlik (QMC) zapewnia aplikacje służące do monitorowania wydajności i użytkowania systemu w Qlik Sense Enterprise on Windows:

Aplikacja Operations Monitor dostarcza informacji na temat stopnia wykorzystania sprzętu, w tym użycia pamięci serwera i procesora CPU, liczby aktywnych użytkowników oraz czynności dotyczących zadań przeładowania. Udostępnia ona również podsumowanie i szczegółowe informacje na temat błędów, ostrzeżeń oraz czynności odnoszących się do dziennika w środowisku serwera Qlik Sense.
Aplikacja License Monitor umożliwia śledzenie wykorzystania licencji i ułatwia monitorowanie zmian dotyczących przydzielania licencji.
Aplikacja Log Monitor prezentuje prawie wszystkie dostępne dane dziennika i umożliwia analizę trendów oraz rozwiązywanie problemów.
Aplikacja Sessions Monitor przedstawia dane logowania dotyczące korzystania z aplikacji.
Aplikacja Reloads Monitor prezentuje szczegółowe informacje na temat przeładowanych danych, zarówno z QMC, jak i z aplikacji otwartych w hubie.
Aplikacja Sense System Performance Analyzer wyświetla wydajność Qlik Sense we wszystkich węzłach.
Aplikacja Sense Connector Logs Analyzer zapewnia wnioski dotyczące użytkowania i błędy konkretnych łączników Qlik.
Aplikacja App Metadata Analyzer zapewnia całościowy widok wszystkich aplikacji Qlik Sense, w tym szczegółowe informacje na temat modelu danych aplikacji i wykorzystania przez nie zasobów.

Więcej informacji zawiera temat Monitorowanie witryny Qlik Sense Enterprise on Windows (tylko w języku angielskim).

Duże ilości danych

Te strategie architektoniczne można zastosować przy łączeniu się z dużymi ilościami danych.

Segmentacja

Można segmentować QVDs według wymiarów, takich jak przedział czasu lub region. Można na przykład mieć:

Plik QVD zawierający dane z dwóch ostatnich lat.
Plik QVD zawierający dane historyczne z okresu dłuższego niż dwa lata.
Plik QVD zawierający wszystkie dane zagregowane na wyższym poziomie. Na przykład na poziomie miesiąca zamiast daty lub według kraju zamiast według klientów indywidualnych.
Jeden duży QVD plik ze wszystkimi danymi, który jest używany tylko przez małą grupę użytkowników.

Aplikacje można segmentować podobnie. Mniejsze aplikacje zaspokoją potrzeby analityczne większości użytkowników. To oszczędza pamięć.

Można mieć również wiele aplikacji skoncentrowanych na różnych regionach. W ten sposób użytkownicy nie będą otwierać aplikacji z danymi, które ich nie interesują lub do których nie mają prawa dostępu. Dane, które nie są dostępne poprzez dostęp do sekcji, nadal wpływają na pamięć.

Generowanie aplikacji na żądanie (ODAG)

Aplikacje na żądanie Qlik Sense zapewniają użytkownikom zbiorcze widoki dużych magazynów danych. Mogą oni identyfikować i ładować odpowiednie podzbiory danych do szczegółowej analizy.

Z perspektywy użytkownika istnieją dwie aplikacje:

Koszyk zakupowy ze zagregowanymi danymi.
Pusta aplikacja szablonu służąca do wyświetlania szczegółów.

Użytkownik dokonuje wyboru w aplikacji koszyka. Po osiągnięciu określonego progu tworzony jest niestandardowy skrypt LOAD, który wypełnia aplikację szablonu żądanymi danymi. Więcej informacji zawiera temat Zarządzanie danymi big data za pomocą aplikacji On-demand.

Łączenie łańcuchowe dokumentów

Łączenie łańcuchowe dokumentów oznacza, że istnieje zagregowana aplikacja, której użytkownicy regularnie używają. Jeśli użytkownik potrzebuje więcej szczegółów, wybory mogą zostać przekazane ze zagregowanej aplikacji do aplikacji szczegółowej, tak aby można było zobaczyć niższy poziom szczegółowości. Oszczędza to pamięć, ponieważ użytkownicy nie ładują niepotrzebnych szczegółów. Łączenie łańcuchowe dokumentów jest obsługiwane poprzez APIs.

Wydajność modelu danych

Są to wskaźniki, które mogą mieć wpływ na wydajność modelu danych. Każdy z nich stanowi najlepszą praktykę, która poprawia użyteczność aplikacji.

Najlepsze praktyki w zakresie wydajności modelu danych
Działanie	Opis
Usunięcie kluczy syntetycznych	Qlik Sense tworzy klucze syntetyczne, gdy co najmniej dwie tabele danych mają dwa lub więcej wspólnych pól. Może to oznaczać, że w skrypcie lub modelu danych występuje błąd. Diagnostyka kluczy syntetycznych, patrz Klucze syntetyczne.
Usunięcie odwołań cyklicznych z modelu danych	Odwołania cykliczne występują, gdy dwa pola mają więcej niż jedną asocjację. Qlik Sense spróbuje je rozwiązać poprzez zmianę połączenia z jedną z tabel. Należy jednak rozwiązywać wszystkie ostrzeżenia związane z odwołaniami cyklicznymi, patrz Rozpoznawanie i naprawianie odwołań cyklicznych.
Odpowiednia szczegółowość danych	Należy ładować tylko te dane, które są niezbędne. Na przykład: grupa użytkowników potrzebuje tylko danych podzielonych według tygodnia, miesiąca i roku. W celu oszczędzenia w pamięci można załadować dane zagregowane lub zagregować dane w skrypcie ładowania. Jeśli użytkownik potrzebuje wizualizacji danych na niższym poziomie szczegółowość, można użyć ODAG lub powiązać łańcuchowego łączenia dokumentów.
Stosowanie plików QVDs tam, gdzie jest to możliwe	QVD to plik zawierający tabelę danych wyeksportowanych z programu Qlik Sense. Ten format pliku jest zoptymalizowany w celu uzyskania maksymalnej szybkości odczytu danych ze skryptu przy zachowaniu niewielkich rozmiarów. Odczyt danych z pliku QVD jest zazwyczaj 10–100 razy szybszy niż odczyt z innych źródeł danych. Więcej informacji zawiera temat: Praca z plikami QVD.
Optymalizacja plików QVD podczas ładowania	Pliki QVD mogą być odczytywane w dwóch trybach: standardowym (szybkim) i zoptymalizowanym (szybszym). Wybrany tryb jest automatycznie określany przez silnik obsługi skryptów. Istnieją pewne ograniczenia dotyczące ładowania zoptymalizowanego. Istnieje możliwość zmiany nazw pól, ale każda z tych operacji spowoduje standardowe ładowanie: Jakiekolwiek transformacje pól, które są ładowane. Użycie klauzuli where, co spowoduje, że program Qlik Sense rozpakuje rekordy. Używanie Map w polu, które jest ładowane.
Wykorzystanie ładowania przyrostowego	Jeśli aplikacja łączy się z dużą ilością danych z baz danych, które są na bieżąco aktualizowane, przeładowanie całego zestawu danych może być czasochłonne. Zamiast tego do pobierania nowych lub zmienionych rekordów z bazy danych należy używać ładowania przyrostowego. Więcej informacji można znaleźć w temacie Ładowanie nowych i zaktualizowanych rekordów za pomocą funkcji ładowania przyrostowego.
Konsolidacja modelu Snowflake	W przypadku modelu danych Snowflake można zmniejszyć liczbę tabel danych, łącząc niektóre z nich przy użyciu prefiksu Join lub innego mapowania. Jest to szczególnie ważne w przypadku dużych tabel faktów. Dobrą zasadą ogólną jest stosowanie tylko jednej dużej tabeli. Więcej informacji w temacie Łączyć, czy nie łączyć.
Tabele z małą ilością pól są zdenormalizowane	W przypadku dwóch tabel z kilkoma polami połączenie ich może poprawić wydajność. Więcej informacji zawiera temat Kolejne etapy tworzenia skryptów.
Zdenormalizowane tabele wyszukiwania (liść) z mapowaniem ładowania	Nie należy używać prefiksu Join , jeśli chce się tylko dodać jedno pole z jednej tabeli do drugiej. Należy użyć funkcji wyszukiwania ApplyMap , patrz Nie łącz – używaj funkcji ApplyMap.
Usunięcie lub odłączenie znaczników czasu od pola daty	Pola dat mogą wypełniać przestrzeń, gdy obecny jest znacznik czasu, ponieważ reprezentacja w postaci ciągu i liczba odrębnych wartości są większe. Jeśli precyzja nie jest konieczna do analizy, możesz zaokrąglić znacznik czasu do np. najbliższej godziny za pomocą funkcji Timestamp(Floor(YourTimestamp,1/24)) lub całkowicie usunąć składnik czasu za pomocą funkcji Date(Floor(YourTimestamp)). Jeśli znacznik czasu ma być obecny, można go odłączyć od samej daty. Można użyć tej samej funkcji Floor(), a następnie utworzyć nowe pole z wyodrębnionym czasem, używając na przykład: Time(Frac(YourTimestamp)).
Usunięcie niepotrzebnych pól z modelu danych	Do modelu danych należy ładować tylko niezbędne pola. Należy unikać Load * i SELECT. Pamiętaj, aby zachować: Pola, które są niezbędne do analizy. Pola, które są faktycznie używane w aplikacji.
Unikanie tabel łączy w przypadku dużych ilości danych	W miarę możliwości należy korzystać z tabel łączy. Jednakże w przypadku dużych ilości danych skonkatenowane tabele mogą zapewniać wyższą wydajność niż tabele łączy.
Rozdzielanie skonkatenowanych wymiarów na nowe pola	Skonkatenowane wymiary należy rozdzielać na osobne pola. Zmniejsza to liczbę unikatowych wystąpień wartości w polach. Jest to podobne do optymalizacji znaczników czasu.
Stosowanie plików AutoNumber tam, gdzie jest to możliwe	Ładowanie zoptymalizowane można utworzyć, najpierw ładując dane z pliku QVD, a następnie używając instrukcji AutoNumber w celu przekształcenia wartości na klucze symboli.Więcej informacji zawiera temat AutoNumber.
Unikanie wysp danych	Wyspy danych mogą być użyteczne, ale zazwyczaj wpływają na wydajność. W przypadku tworzenia wysp dla wartości wyboru należy używać zmiennych.
Przechowywanie plików QVD w oparciu o przyrostowe przedziały czasu	Pliki QVD należy przechowywać w segmentach, np. miesięcznych. Te mniejsze miesięczne pliki QVD mogą następnie obsługiwać wiele różnych aplikacji, które niekoniecznie będą potrzebować wszystkich danych.

Wydajność arkuszy

Są to najlepsze praktyki, które poprawią wydajność arkuszy i wizualizacji.

Najlepsze praktyki w zakresie wydajności arkuszy
Działanie	Opis
Unikanie funkcji If() w miarę możliwości	Jeśli funkcja If() jest używana wewnątrz funkcji agregującej, będzie działać na poziomie rekordu i zostanie wielokrotnie oceniona. W przypadku 1000 rekordów w agregacji warunek If() zostanie oceniony 1000 razy. To może szybko kaskadować w przypadku zagnieżdżania instrukcji. Zamiast niej należy użyć analizy zestawów. Przed agregacją stosowany jest filtr analizy zestawów, co powoduje szybszą odpowiedź. Odpowiedzi te mogą być również buforowane za pomocą analizy zestawów, tymczasem w przypadku funkcji If() nie jest to możliwe. Można również rozważyć inne funkcje i modyfikacje modelu danych.
W miarę możliwości w tabeli agregacji unika się pól z różnych tabel.	Podczas oceny agregacji obliczenia przebiegają w dwóch etapach: Pierwszym krokiem jest znalezienie odpowiednich kombinacji, na których należy dokonać obliczeń. Ten krok jest jednowątkowy. Drugim krokiem jest wykonanie obliczeń. Ten krok jest wielowątkowy. Część jednowątkowa może znacząco wpłynąć na wydajność. Jednym z przykładów jest sytuacja, gdy w agregacji znajduje się wiele pól, na przykład Sum(Quantity*ListPrice). Jeżeli Quantity znajduje się w tabeli faktów, a ListPrice znajduje się w tabeli produktów głównych, aparat musi najpierw połączyć obie tabele, aby znaleźć kombinacje, zanim będzie mógł rozpocząć sumowanie produktu. Łączenie jest częścią jednowątkową, a sumowanie jest wielowątkowe. Jeśli oba pola znajdują się w tej samej tabeli, łączenie nie jest konieczne, a agregacja jest oceniana znacznie szybciej.
Korzystanie z funkcji Aggr() i zagnieżdżonej funkcji Aggr() w stopniu minimalnym	Funkcja Aggr() znacząco wpływa na wydajność. Niewłaściwe użycie może dać niedokładne wyniki. Na przykład w tabeli z wymiarami, które różnią się od wymiarów w funkcji Aggr(). Więcej informacji w temacie Kiedy nie używać AGGR?
Stosowanie analizy zestawów, gdy jest to możliwe	Za pomocą analizy zestawów można zdefiniować zestaw wartości danych, który różni się od zwykłego zestawu określonego przez aktualne wybory. Więcej informacji można znaleźć w temacie Analiza zestawów.
Unikanie porównań ciągów w miarę możliwości	Porównania ciągów nie są tak wydajne jak analiza zestawów. Na przykład należy unikać Match(), MixMatch(), WildMatch() oraz Pick(). Należy tworzyć flagi w skrypcie lub używać analizy zestawów. Więcej informacji w temacie Funkcje warunkowe oraz Wydajność agregacji warunkowych.
Stosowanie warunków obliczania na obiektach zawierających złożone obliczenia	Można mieć wizualizacje z wieloma rekordami, gdy nie ma żadnych wyborów. Najlepszą praktyką jest dodawanie warunków obliczania do obiektów, tak aby były one renderowane dopiero po dokonaniu określonych wyborów. Zapobiega to powstawaniu bardzo dużych hiperkostek. Na przykład: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. W tym scenariuszu wizualizacja nie zostanie wyrenderowana, jeśli użytkownik nie wybierze jednego kraju lub nie dokona innych wyborów, w których możliwy jest tylko jeden kraj.
Wstępne obliczanie miar w skrypcie w miarę możliwości	Każda miara, która znajduje się na najniższym poziomie szczegółowości modelu danych powinna być obliczana w skrypcie. Jeśli na przykład w tym samym rekordzie w tabeli występuje Sales oraz Cost, można uzyskać wartość marży poprzez obliczenie Sales - Cost AS Margin. Można również agregować inne wartości z wyprzedzeniem, jeśli wiadomo, że nie będą się one różnić w zależności od wyboru lub że są one związane z innym poziomem szczegółowości.
Tabele mają mniej niż 15 kolumn i mają warunki obliczania	Tabelę z 15 kolumnami można uznać za szeroką. Jeśli tabele składają się z wielu rekordów, należy użyć obliczonych warunków na obiekcie tabeli tak, aby renderował się tylko po spełnieniu pewnych kryteriów lub wyborów. Jeśli tabela jest bardzo szeroka, należy rozważyć następujące opcje: Utworzenie wielu mniejszych tabel, które są wyświetlane warunkowo. Używanie metod do warunkowego wyświetlania kolumn. Ograniczanie tabel tylko do tych pól, które są niezbędne do analizy.
Arkusze nie mają zbyt wielu obiektów	Obiekty są obliczane, gdy użytkownik przechodzi do arkusza. Za każdym razem, gdy użytkownik dokonuje wyboru na tym arkuszu, każdy obiekt zostaje ponownie obliczony, jeśli ten aktualny stan nie istnieje w pamięci podręcznej. W przypadku arkusza z wieloma wykresami użytkownik będzie musiał czekać na obliczenie każdego obiektu przy niemalże każdym wyborze. Stanowi to znaczne obciążenie dla silnika. Najlepiej postępować zgodnie z koncepcją Dashboard/Analysis/Reporting (DAR) , aby utworzyć przejrzystą i minimalistyczną aplikację. Więcej informacji w temacie Metodologia DAR.
Stosowanie flag numerycznych w skrypcie do wykorzystania w analizie zestawów	Analiza zestawów z flagami może być bardziej efektywna niż porównywanie lub mnożenie ciągów.
Używanie elementów głównych lub zmiennych w wyrażeniach	Elementy główne umożliwiają przeciąganie i upuszczanie zarządzanych wskaźników oraz gwarantują, że wyrażenia zostaną zbuforowane. Na przykład Sum(Sales) różni się od SUM(Sales). Wyrażenia są buforowane z pisownią oraz wielkością liter i muszą pasować słowo w słowo, aby mogły być ponownie użyte.

Czy ta strona była pomocna?

Jeżeli natkniesz się na problemy z tą stroną lub jej zawartością — literówkę, brakujący krok lub błąd techniczny — daj nam znać, co możemy poprawić!

Przekaż tu opinię