Values are loading slowly

[kaushi2020]

Hi Everyone,

I have multiple KPI objects in my sheet. when I am loading this app it takes sometime to load the numbers. is there any way we can improve the loading. (Currently the data is loaded from a QVD).

thanks in advance.

[Nicolae_Alecu]

Hello,

It takes some time to load the app? or the KPI object ? 

If it takes some time to display the values in kpi object, the problem could be a inappropriate data model or because you're not using set analysis in measures. (Try to avoid if statements in measures)  

For slowly app reload, you could consider to modify "SET CreateSearchIndexOnReload=0;" , and be make sure your qvd is optimize loaded.

It could be a cache problem, because at the first open after reload, data need to be cached so you may experience slow performance. 

Also, you could consider to check your server resources.

[qv_testing]

ofcourse it will be lag to load the KPI's, because you have many of them.

my suggestion, 

you have to optimize expressions and if you have any complex expressions try to implement script level.

[marcus_sommer]

Don't use KPI-objects else a table. Yes, you couldn't layout the table like the KPI's but you could provide the same information.

[kaushi2020]

we are using a basic expression to calculate the values. 

Sum({$<Year=, Month=, Day=,GA_RP_Type={'VOICE},
Date={">=$(=date(yearstart(max(Date))))<=$(=date(max(Date)))"}>}
Count)

[kaushi2020]

Thanks for the reply, what is that which is making the app load very slow may be Qlik Support can check. Table is quick but the way these numbers are presented cannot be represented using a Table. 

If you see these numbers, the presentation looks very well. but when  we use a Table, it will not give the same impression. a CEO will not feel it interesting when we present in table ? 🙂 how you understand. please let me know your views.

@Support @Sonja_Bauernfeind 

[marcus_sommer]

The most heavy calculation by an UI object is the dimensional context behind it which means that a virtual table is created. AFAIK this part is until nowadays a single-threading measurement and on top of it are then the multi-threading aggregations performed.

If your sheet has now a few dozend of such virtual tables to create it must be slower as a table with a single one. Beside this a table must not mandatory look like a table - I don't know Sense good enough to guide you here or to recommend any extensions but in QlikView there are various possibilities to adjust a table to provide an easy readable layout and all essential information.

Before going further with the layout-stuff I suggest to review the data-model it's really suitable for your UI performance requirements. Officially recommended is the use of a star-scheme which means to have a single fact-table and n surrounding dimension-tables. And it may further be extended with different granularities to calculate the CEO views on consolidated data other may go against atomic ones:

https://community.qlik.com/t5/Design/Fact-Table-with-Mixed-Granularity/ba-p/1468238

[kaushi2020]

thanks for your suggestion. Currently this is how the model looks like. 

here we show data based on MTD (Month to Date) logic. where the data we show is of month start till max of day. hence the model is connected to master calendar. 

Is there any way we can achieve this format using a table ?

[marcus_sommer]

There might be scenarios in which such a data-model is suitable but I doubt that's a good choice in your case. There are several fact-tables which are just connected against a date. This means there are no other dimensional views possible unless the period-fields and missing key-values respectively dates on any side could become problematic. I never used such data-model but I think it will have also disadvantages in regard to the performance.

Essentially is the understanding that facts like sales & budget & forecast and similar are the same kind of data - only the point of view goes in another direction. This means such data could be loaded per concatenate into the same table by harmonizing all field-names and data-structures as much as possible and ending with single field of type, category, sub-category, values, counts and not different ones in each table. A single extra field of 'sales' respectively 'budget' as SOURCE would be enough to be able to differentiate between them in dimensions, selections and/or conditions.