Discussion :

[drecker]

Bonjour,


Depuis quelques temps, noues avons des problèmes de temps de chargement des données au niveau de certaines de nos feuilles dans QLIK Sense.

Il s'agit en général de feuilles avec un listing et des filtres.

Nous avons beau gérer dans une autre feuille d'une même application le choix des filtres afin de réduire au maximum le volume de données à afficher, le temps de chargement reste rédhibitoire, au point de ne jamais afficher les données ("Time out", "Délai de calcul trop long").
Celà dit, avec l'application d'aucun filtre, le nombre d'enregistrement est d'environ 9-10 millions avec une quinzaine de champs.

Comment faire afficher de gros listings dans QLIK Sense?
Faudrait - il revoir la source de données (nous gérons souvent un système de "modèle en étoile" avec une quinzaine de "tables").

Sinon, de manière général, comment vous y prenez vous pour gérer d'aussi gros volumes de données?

Je reste à disposition et vous remercie par avance de vos réponses.

[PhunkyBob]

Bonjour,

Qu'entendez-vous par "temps de chargement" ?
C'est le moment entre le clic sur une sélection et l'affichage du résultat dans le navigateur ?

Normalement, gérer 10 M de lignes ne devrait pas poser de problème. Il faut voir quelles sont les expressions dans vos graphiques (s'il y a des produits cartésiens, c'est sur que ça monte vite en RAM).
Est-ce qu'une feuille qui ne contient que des listes de sélection est aussi lente à calculer ?


De combien de RAM dispose votre serveur ?
Quelle quantité de RAM est consommée par QlikSense ?

[nuke_y]

Quelle version de Sense ? Client lourd ou serveur ?

Avez-vous des extensions ?

Ca ne m'étonne pas que l'affichage d'un grand nombre de valeurs soit extrêmement lent en Sense, on a mal été habitués par le temps exceptionnellement rapide de Qlikview.

Si je comprends bien le besoin vous voulez pouvoir afficher un tableau avec 15 colonnes et 10 M de lignes, et pouvoir faire des filtres qui réduisent le nombre de ces lignes.

Donc au maximum 150 M de cellules à lire dans l'hypercube, mettre en forme, placer dans un objet html généré à la volée. Au minimum... ça dépend du nombre de lignes.

Pouvez-vous tester une combinaison de filtres qui donnerait 1000 lignes seulement et voir le temps d'affichage et la RAM consommée?

Puis une autre combinaison qui donnerait 10 000 lignes et refaire les tests

et ainsi de suite jusqu'à 10 M pour voir la courbe de temps d'affichage et de consommation de RAM ?

Merci

[drecker]

Le serveur est un serveur de 32Go de RAM

Le processeur est décris comme -ci : Intel ® Xeon CPU E5-2630 0 @2,3GHz 2,29GHz (2 processeurs).
On va dire qu'environ 17Go de RAM au moins est entièrement dédié à QLIK.

Je voulais dire par temps de chargement le temps que met la feuille pour afficher le listing.

Sinon, même en mettant des filtres, le problème ne se résout pas (c'est comme s'il fallait systématiquement que l'application traite la totalité des données avant de filtrer et non l'inverse).

Il y a 5 champ avec des formules de type set analysis, même en supprimant les formules (mais en gardant les champs), le problème persiste... ca semble vraiment lié au nombre de lignes et apparemment, c'est trop ces millions de lignes venant de la source de données.

Voici deux captures que j'ai pendant que je tente de charger la page :




Merci en tout cas de vos réponses.

[nuke_y]

D'après mes tests:
- le nombre de lignes du modèle n'a pas d'influence (disons pas plus qu'en Qlikview)
- 1 000 lignes dans le tableau, 4 colonnes (3 dimensions, 1 mesure) : long mais ok
- 5 000 lignes dans le tableau, 4 colonnes (3 dimensions, 1 mesure) : long mais ok
- 7 500 lignes dans le tableau, 4 colonnes (3 dimensions, 1 mesure) : long mais ok
- 9 000 lignes dans le tableau, 4 colonnes (3 dimensions, 1 mesure) : ko : mémoire insuffisante (alors que la RAM ne montre pas de saturation)
- 10 000 lignes dans le tableau, 4 colonnes (3 dimensions, 1 mesure) : ko : mémoire insuffisante (alors que la RAM ne montre pas de saturation)
- si on tente de créer la visualisation avec un filtre appliqué qui réduit fortement le nombre de lignes : ça marche puis quand on enlève le filtre : erreur "mémoire insuffisante"
- si on tente de créer la visualisation sans filtre appliqué puis qu'on quitte le mode Edition : mouline pendant un moment puis erreur "Echec de rendu de la visualisation"
- aucun message d'erreur dans la console
- listbox jusqu'à 10 M d'éléments ok, 100 M ça bloque (mais parfois il s'en sort) + consommation importante de RAM et de CPU

Bref, plus de 40 000 cellules, ça semble mal passer.

[drecker]

En fait, il s'agit d'un tableau de 17 champs et 4 mesures.
Je crois qu'on pourrais passer de 4 à une seule mesure mais le soucis est qu'il nous faut réaliser un filtre sur un temps.
Nous avons en filtre deux temps et nous voulons des lignes ayant des dates comprises dans cet intervalle de temps.
Nous ne voyons pas d'autres solution que d'uiliser un set analysis dans un champ "Mesure".
Et dans la base il y a plus de 9 millions d'enregistrements.

Comment dans QLIK afficher un listing répondant à ces besoins sans que ça plante?

[nuke_y]

je n'ai pas bien compris le besoin mais la contrainte technique c'est : ne pas afficher plus de quelques milliers de cellules. Quand on passe dans l'ordre de plusieurs dizaines de milliers ça risque de planter. Après il peut exister du paramétrage mais je ne l'ai pas encore trouvé.

Pouvez-vous ré-expliquer en détail le besoin ?

Mercoi

[PhunkyBob]

Assurez vous bien que pour filtrer sur le temps (entre 2 dates), vous le faites bien par Set Analysis (filtre optimisé en utilisant la structure vectorielle), et pas par un "if" dans l'expression (qui lui va parcourir toutes les données, même si c'est pour en ressortir que quelques lignes).

[drecker]

Le filtre sur le temps se fait bien par un set analysis.

Sinon, il y a bien plus de 40 000 cellules (car sans les filtres il y a quelques millions de lignes et une vingtaine de champs)... 40000, ça me semble très peu.

[nuke_y]

40 000 ça parait peu c'est vrai mais 10 000 <tr></tr> et 40 000 <td></td> voire <tr class="....."> et <td class="...."> ça commence à faire beaucoup. Sachant que c'est le navigateur côté client qui va devoir traiter ça, le serveur n'aidera en rien.

C'est pour ça que le web a développé des approches telles que la pagination ou Ajax.

Bref sans une description plus claire du besoin on ne pourra pas avance plus.

A noter que certes la remarque de PhunkyBob est tout à fait correcte dans l'absolu mais dans ce cas précis je ne pense pas que le problème vienne du traitement serveur, mais de la partie affichage client. En gros l'hypercube a bien été généré et renvoyé au client, c'est la construction du rendu qui n'aboutit pas.

[PhunkyBob]

Question bête : où est le client ?
Est-ce qu'on a les mêmes temps entre un client qui passe par internet et un client en local (exécuté sur le serveur, en utilisant le localhost) ?

[nuke_y]

A la réflexion je suis peut-être parti sur une fausse piste. Pouvez-vous envoyer des screenshots des messages d'erreur svp ? "Délai de calcul trop long" semble être une erreur côté serveur, on serait donc plus dans la piste creusée par PhunkyBob : un problème de modèle ou d'expression.

[drecker]

Voici le message d'erreur que ça affiche.

Sinon, les personnes concernées par ce problème utilisent QLIK Sense via Internet.

[nuke_y]

C'est une extension ou un objet natif ?

[nuke_y]

Bon visiblement au moins UNE autre personne a eu le problème : https://community.qlik.com/thread/169085

Si l'accès se fait via internet (et pas intranet hein ?) alors le problème peut venir aussi du taux de transfert des données de l'hypercube.

En gros le time out peut arriver:

- lors du calcul de l'hypercube : comment diagnostiquer ? Conserver une seule expression, simplifiée, qui fasse qu'on a toujours le même nombre de lignes. Eventuellement mettre le modèle de données dans Qlikview (même version personnelle) et voir si ça marche. Au moins Qlikview n'a pas obligatoirement un affichage Web.

- lors du transfert de l'hypercube entre le serveur et le navigateur : comment diagnostiquer ? Aucune idée, tracer les trames peut-être.

- lors du calcul de l'objet pour afficher les données : comment diagnostiquer ? Créer une extension (c'est pas si compliqué) qui prend les dimensions et mesures utilisés dans votre application et qui affiche un "top" (console.log("top")) au début de la méthode paint. Ca prouvera que le tranfert de l'hypercube est ok et que c'est l'affichage qui ne marche pas.

[PhunkyBob]

- lors du transfert de l'hypercube entre le serveur et le navigateur : comment diagnostiquer ? Aucune idée, tracer les trames peut-être.

C'est justement pour ça que je demandais s'il y avait une différence entre une utilisation en local (depuis le serveur) et depuis le client.

[nuke_y]

@PhunkyBob: oui, c'est une bonne idée pour diagnostiquer ce problème là.

[drecker]

Merci de vos réponses en tout cas.

Mais j'ai une petite question.
A votre avis, pour une application donnée, un temps de recharge des données de plus d'une heure, est-ce que ça vous parait beaucoup ou pas?

Apparemment, le temps de charge des données semble proportionnel au volume des données surtout (même si la complexité des codes sql est impactante également je pense).

[PhunkyBob]

Je ne vois rien de choquant à ce qu'un reload prenne plus de 1 heure.

J'ai des applications qui mettent 18 heures pour se recharger.
Rien que la lecture (sans traitement) d'un CSV de plus de 150 Go prend environ 1 heure.

[nuke_y]

Idem, j'ai des applications longues avec "seulement" quelques millions de lignes mais des centaines de transformations, des applications longues avec peu de transformations mais des centaines de millions de lignes.

Rien de choquant