Qlikview Server Extremely Slow Load Times

[#1]

Hello,

I have a dashboard that loads quickly on my local machine but takes much longer to load when hosted and viewed from our Qlikview server. The dashboard utilizes alternate states and set analysis, which could be contributing to the long load times--I just have no way of knowing. I suspected that the nested if statements in some of my charts was contributing to the long load times, so instead of using one chart and a nested if statement to pull data from the model depending on the value of a particular variable, I created a unique chart for each variable and used conditional show in the layout menu to control when the chart was visible. Based on some preliminary tests this had little to no effect on the load times.

Does anyone know any other potential reasons for my dashboard to be slow in Qlikview Server? I have noticed that it performs much slower in IE than it does in Chrome or Firefox, but we unfortunately need to offer the dashboard in all browsers so I'm looking for other possible solutions. Any help would be much appreciated!!

Best,

Geoff

[Peter_Cammaert]

QlikView AccessPoint performance largely depends on three factors:

• server resources: enough RAM and CPU cores are the basis for an enjoyable AP visit.
• document efficiency (optimizing expressions, field content, using set analysis instead of IFs, reducing cardinality all provide sometimes incremental, sometimes massive speed improvements)
• client performance: while many people think that performance is the exclusive territory of the server, the client browser can sometimes have an even bigger (negative) impact on performance than the server.

As of now, your end-users should avoid using IE for QlikView document access for a simple reason: the awful performance of the builtin javascript engine, which does most of the heavy lifting. The difference between Chrome and IE can be as much as 2x, 3x to 10x better in Chrome. Spartan/Edge/Whatever-IE12-is-called will bring substiantial performance improvements this summer, but I'm not sure that you or your company will switch browsers the moment IE12/Win10 becomes available.

Peter

[marcus_sommer]

Beside the hardware numbers of cpu, ram and so on it could make a bigger difference if the hardware is physically or virtual. Virtual environments needs to be configured very carefully then qlikview needs always access to fix ressources of cpu + ram. This meant none shared ressources.

- Marcus

[#4]

Many thanks for the detailed reply, Peter. Could you explain a bit about cardinality? Does that mean the amount of components that I'm trying to load on each page? I suspect that this might be the issue and plan to test.

[Peter_Cammaert]

Not really. Cardinality refers to the number of discrete values in a field. Large (unwarranted) numbers of discrete values have a negative impact on Qlik preformance, due to the fact that the associated symbol table becomes huge, and (bit-stuffed) pointers into this table grow as well. The technical details may not appeal to you, but an example will make things clear:

Storing a very large number of date and time values in a single timestamp field will make both performance and compression worse than storing dates and times in different fields. It your data model only contains a limited amount of rows, the difference won't be noticeable. It is a best practice to not keep the details (for example minutes, seconds and fractions in a time field) if you have no use for them.

Peter