QAPOS facilite un cycle de vie de mesure et d’amélioration de la performance comme suit:
1. Définir les critères de performance.
Voici des exemples de critères: Un temps de réponse moyen de 8 secondes ou moins est acceptable, où le temps de réponse est le temps écoulé entre une entrée utilisateur (clic) et le moment où tous les graphiques ont terminé le calcul et le rendu. Les temps de réponse moyens sur 8 secondes doivent être fournis avec une population de 1 000 utilisateurs simultanés, chaque utilisateur réfléchissant en moyenne 1 minute après chaque réponse du système.
2. Mesurez les performances avec les applications de base, la charge de travail et la configuration matérielle.
3. Appliquez une modification d’application proposée (candidat à l’optimisation) dans un environnement de test. Les stratégies (QAPOS) décrites dans ce document spécifient les domaines dans lesquels identifier les candidats à l’optimisation.
4. Mesurer les performances après la mise en œuvre du changement proposé et comparer les performances de base (étape 2) avec ces performances modifiées, ainsi qu’avec les critères définis à l’étape 1.
• Un simple test manuel du chronomètre peut fournir des résultats initiaux pour justifier des tests de performance supplémentaires du changement proposé, à la fois dans QlikView et Qlik Sense.
• Dans QlikView, l’objet CalcTimes peut également fournir un mécanisme de test de performance d’unité utile, comme décrit à l’annexe 1. Le PMPT est un autre outil de test de performance d’unité QlikView utile, décrit à l’annexe 2.
• Les tests de système multi-utilisateurs complets peuvent être automatisés avec les outils de modularité pour Qlik Sense et QlikView.
5. Si la performance modifiée est meilleure; le changement est une optimisation validée; promouvoir l’optimisation à la nouvelle ligne de base.
6. Répétez les étapes 2 à 5 jusqu’à obtenir des performances acceptables (telles que définies à l’étape 1).
Les pages suivantes décrivent chacun des 7 QAPOS.
QAPOS 1: Objets et expressions de refactor
Ici, nous discutons de deux catégories de refactoring: Réduire le temps de calcul d’objet (qui ne nécessite pas de changement d’interface utilisateur) et Réduire la fréquence de calcul d’objet (qui peut nécessiter un changement d’interface utilisateur).
A. Diminuer le temps de calcul des objets (sans modifications de l’interface utilisateur)
Les objets Qlik (tels que les graphiques) et les expressions qu’ils contiennent sont analogues aux requêtes d’agrégation SQL. De la même manière qu’il existe généralement plusieurs requêtes SQL possibles (chacune avec des caractéristiques de performances distinctes) pour obtenir une sortie souhaitée, il existe souvent plusieurs façons de construire un objet Qlik et ses expressions constitutives pour obtenir un résultat spécifique. En tant que tel, une stratégie d’amélioration des performances de Qlik très puissante est la refactorisation d’objets et d’expressions, avec les étapes suivantes:
1. Consultez les résultats affichés par l’objet sous différents états de sélection.
2. Examinez l’ensemble de l’objet (y compris les expressions constitutives et les variables) pour comprendre comment il effectue les calculs par rapport au modèle de données.
3. Concevez et implémentez des versions d’objet de remplacement offrant le même résultat que l’objet d’origine. Dans certains cas, il peut être intéressant d’ajouter un champ au modèle de données pour permettre la création d’un objet plus efficace. Un exemple courant de ce concept consiste à remplacer une dimension calculée dans un graphique par une dimension basée sur un nouveau champ de modèle de données.
4. Testez les performances des versions d’objet alternatives. Si les performances modifiées sont meilleures dans l’une des versions alternatives, promouvez cette version dans la nouvelle ligne de base.
B. Diminuer la fréquence de calcul d’objet (peut nécessiter des modifications de l’interface utilisateur)
Le moteur de calcul Qlik recalcule tous les objets d’interface utilisateur lorsqu’il détecte qu’une action de l’utilisateur (par exemple une sélection dans un champ) a un impact sur les données affichées dans l’objet d’interface utilisateur. En tant que tel, il est utile dans de nombreux cas de désactiver le calcul d’un objet à certains moments. Considérez les étapes suivantes effectuées par un utilisateur :
1. Cliquez sur le bouton Ouvrir les filtres pour afficher les zones de liste des champs de dimension.
2. Sélectionnez les valeurs dans le champ de dimension A.
3. Sélectionnez des valeurs dans le champ de dimension B.
4. Cliquez sur le bouton Fermer les filtres pour masquer les zones de liste des champs de dimension.
5. Voir les graphiques.
Si tous les objets de l’interface utilisateur sont recalculés entre chaque interaction utilisateur, un délai perceptible peut se produire entre chaque clic, ce qui crée une expérience utilisateur lente composée d’une séquence de retards. En tant que tel, il est souvent avantageux de désactiver le calcul des graphiques gourmands en ressources jusqu’à ce que l’utilisateur indique (en cliquant sur un bouton Fermer filtres ou un bouton similaire) qu’il souhaite afficher les graphiques. Le délai de calcul du graphique est mis en œuvre simplement en définissant le calcul des objets de la feuille ou des conditions d’affichage, de sorte que les objets ne soient pas affichés ou calculés si l’utilisateur n’a pas encore cliqué sur Fermer les filtres.
QAPOS 2: Réduire la complexité du modèle de données
Les possibilités de consolidation des modèles de données comportant plus de 25 tables doivent être évaluées, car un plus grand nombre de tables augmente les temps de réponse à l’exécution du fait de la fréquence accrue des traversées de tables.En bref, un modèle de données avec plus de tables est généralement moins efficace qu’un modèle avec moins de tables.
Pour améliorer les performances des utilisateurs finaux dans les modèles de données contenant plus de 25 tables, réduisez le nombre de tables en joignant des tables comportant moins de quatre champs dans la table liée de manière logique (à moins qu’une relation plusieurs-à-plusieurs entraîne une multiplication des enregistrements et / ou données non valides). Une consolidation plus poussée (et des améliorations des performances d’exécution) du modèle de données peut souvent être réalisée en créant une table de faits unifiée commune, à l’aide de techniques Qlik telles que JOIN ou CONCATENATE.
En bref, la recommandation générale est de viser un modèle de données ayant des caractéristiques plus proches d’un schéma en étoile qu’un schéma en flocon de neige, car le nombre réduit de tables dans le schéma en étoile entraîne moins de déplacements de tables chronophages.
QAPOS 3: lignes de faits pré-agrégées (consolidées)
Un nombre réduit d’enregistrements (lignes) de table de faits, avec une diminution correspondante du temps de réponse, peut potentiellement être obtenu en consolidant les lignes de faits (conceptuellement) comme suit:
Le processus de base consiste à stocker les champs de métrique dans la table de faits Qlik à la granularité la plus élevée à laquelle l’utilisateur final doit afficher les métriques. La pré-agrégation des champs de métrique peut être effectuée assez facilement dans le script Qlik avec la construction Group by. Le temps requis pour l’agrégation des données de niveau transaction jusqu’au niveau supérieur (le niveau de région dans cet exemple) est consommé pendant le processus d’actualisation des données Qlik (auquel l’utilisateur final n’est pas directement exposé) afin de réduire le temps de réponse d’exécution de l’application (telle que vécue directement par les utilisateurs finaux). Bien qu’il soit généralement avantageux de réduire les temps de réponse des utilisateurs finaux, le compromis entre la consommation de temps entre l’actualisation des données et l’exécution de l’application doit être évalué en tenant compte des exigences de performances et des cycles d’actualisation des données.
QAPOS 4: liens de table de rationalisation
Remplacer les clés textuelles par des clés numériques: les clés numériques du modèle de données Qlik consomment moins d’espace et permettent des performances d’exécution potentiellement plus rapides que les clés textuelles.
Comme pour la stratégie précédente (consolidation des lignes de faits), il convient d’évaluer le compromis entre les temps de réponse à l’exécution et la durée d’actualisation des données; La conversion de clés textuelles en clés numériques (généralement avec la fonction Qlik AutoNumber) apportera probablement une réponse plus rapide au moment de l’exécution aux utilisateurs finaux tout en augmentant potentiellement les temps d’actualisation cyclique des données
QAPOS 7: Segmenter l’application
Une seule application logique peut être divisée en plusieurs fichiers QVW ou QVF physiques, chaque fichier étant chargé «à la demande» de manière transparente. Cette division physique peut fournir des temps de réponse plus courts aux utilisateurs finaux, car les QVW ou QVF segmentés actifs à un moment donné sont inférieurs à un seul QVW ou QVF monolithique, avec un ensemble d’enregistrements plus petit sur lequel les expressions de graphique doivent être agrégées. Le chaînage de documents et la génération d’applications à la demande sont deux formes de segmentation d’applications couramment utilisées.
Annexe 1: Test des performances de l’unité avec CalcTime (QlikView uniquement)
Lors du développement du tableau de bord QlikView, nous pouvons utiliser CalcTimes pour tester facilement l’impact des modifications sur les performances. CalcTimes au niveau de l’objet peut être visualisé dans les propriétés de chaque feuille. CalcTime est l’heure d’horloge murale en millisecondes entre l’action de l’utilisateur (clic) et l’heure à laquelle l’objet affiche les résultats du calcul.
Dans les propriétés de la feuille, la liste d’objets peut être triée par CalcTime. La durée CalcTime la plus élevée représente le temps de réponse de la dernière action terminée (sélection ou transition de feuille); Le temps de réponse est le temps qui s’écoule entre le clic de l’utilisateur et la fin du calcul de tous les objets de la feuille. En raison de la simultanéité, les objets CalcTimes des objets ne sont pas additifs; plus haut CalcTime nous indique le temps de réponse de bout en bout. Par exemple, la capture d’écran immédiatement au-dessus indique que le temps de réponse pour la dernière action terminée était de 3994 millisecondes, heure à laquelle le dernier objet, CH01, a terminé le calcul.
En supposant une plate-forme matérielle de taille équivalente pour QV Desktop et QV Server, le temps de réponse des utilisateurs finaux via QlikView Server (pour les calculs non mis en cache) sera généralement supérieur aux meilleurs nombres reflétés dans CalcTimes dans QlikView Desktop. En raison de la latence du réseau et du conflit de ressources entre plusieurs utilisateurs. Quoi qu’il en soit, CalcTimes fournit un mécanisme utile pour tester les performances des unités comparatives d’options de mise en œuvre alternatives.
Notez que QlikView Server et Qlik Sense Server fournissent tous deux une mise en cache intersession. les résultats de calcul pour une application particulière et l’état de sélection d’un utilisateur donné peuvent être stockés et fournis très rapidement à d’autres utilisateurs à un moment ultérieur. Les avantages obtenus par la mise en cache intersession peuvent être simulés dans QlikView Desktop en ne nettoyant pas le cache immédiatement avant de faire une sélection pour la deuxième fois. Pour simuler un état non mis en cache et les CalcTimes supérieurs qui en résultent, un bouton ClearCache peut être utilisé pendant le développement. Ce bouton ClearCache doit appeler une macro, définie comme suit:
sub ClearCache
ActiveDocument.ClearCache
msgbox « Cache has been cleared. »
end sub
