Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi All,
My Qliksense app is taking around 3 mins to load at client side and size is around 2 GB.
Dashboard is having 7 combo charts which are designed using Pick Match functions.
The first user that enter to this module suffer from a long loading time,
and also a user that do the first selection for a certain dimension.
I encounter on the QS documentation in the option of "cache warmer" [link below]
Does anyone used that? Is it helpful? how can we run it on our server?
Could anyone please advise me ?
@Michael_Tarallo , Henric_Cronström, sunny_talwar,Rwunderlich
Regards
Krishna
Yes, you can definitely use the cache warmer in your environment.
However, you first need to understand why the app takes 3 minutes to load: is it network activity, security, limitations on the laptop browser or resources...? Do you see the same when you open the app in your laptop? And when you open the app in the server itself? And if you export the app and open it locally in your computer?
Applying the cache warmer can be extremely beneficial for a set of use cases when you know that aggregations and caching are what takes longer.
But it will do little if, as I have seen quite extensively, the network is slow between the user laptop and the Qlik Sense server, for example.
Cache warming may not be effective either if the app is using a poorly performing data model and expressions (very long and complex expression, variables within variables), or section access.
I'd strongly recommend you to further troubleshoot the environment using other tools such as the Scalability Tools (https://community.qlik.com/t5/Qlik-Scalability/Qlik-Sense-Scalability-Tools/gpm-p/1490846 - to simulate the load without static contents) and monitor the activity on the server side using the App Metadata Analyzer (https://help.qlik.com/en-US/sense-admin/April2020/Subsystems/DeployAdministerQSE/Content/Sense_Deplo...), the Telemetry Dashboard (https://support.qlik.com/articles/000044757) or the System Performance Analyzer (https://help.qlik.com/en-US/sense-admin/April2020/Subsystems/DeployAdministerQSE/Content/Sense_Deplo...) as well as Windows own Performance Counters (see a summary explanation here http://www.appadmintools.com/documents/windows-performance-counters-explained/ but plenty of other resources out there) before making a decision on what is the best approach.
Yes, you can definitely use the cache warmer in your environment.
However, you first need to understand why the app takes 3 minutes to load: is it network activity, security, limitations on the laptop browser or resources...? Do you see the same when you open the app in your laptop? And when you open the app in the server itself? And if you export the app and open it locally in your computer?
Applying the cache warmer can be extremely beneficial for a set of use cases when you know that aggregations and caching are what takes longer.
But it will do little if, as I have seen quite extensively, the network is slow between the user laptop and the Qlik Sense server, for example.
Cache warming may not be effective either if the app is using a poorly performing data model and expressions (very long and complex expression, variables within variables), or section access.
I'd strongly recommend you to further troubleshoot the environment using other tools such as the Scalability Tools (https://community.qlik.com/t5/Qlik-Scalability/Qlik-Sense-Scalability-Tools/gpm-p/1490846 - to simulate the load without static contents) and monitor the activity on the server side using the App Metadata Analyzer (https://help.qlik.com/en-US/sense-admin/April2020/Subsystems/DeployAdministerQSE/Content/Sense_Deplo...), the Telemetry Dashboard (https://support.qlik.com/articles/000044757) or the System Performance Analyzer (https://help.qlik.com/en-US/sense-admin/April2020/Subsystems/DeployAdministerQSE/Content/Sense_Deplo...) as well as Windows own Performance Counters (see a summary explanation here http://www.appadmintools.com/documents/windows-performance-counters-explained/ but plenty of other resources out there) before making a decision on what is the best approach.
The help link that you referred to is merely an example of how to build your own cache warming application using the Qlik Sense Enterprise .NET SDK. My team has covered a handful of other pre-built solutions here, which are generally ideal for most customers.
I'd cosign @Miguel_Angel_Baeyens recommendation to look into tuning the app as well. If there are fundamental design issues with the app, preloading is merely masking the symptoms, not fixing the root cause.
Hi Levi_Turner and Miguel_Angel_Baeyens many thanks to you both for shedding lights on this issue.
My datamodel is not much complicated having only 1 fact and 3 dimension tables.
On users UI request, I have built a 7 combo charts using pick and match functions which has 8 Dimensions and 11 Expressions. Is my app slowing because of these functions?
Regards
Krishna
Pick() and Match() are conditional functions, not aggregation functions (Sum, Count, etc.), so using those in a chart or KPI can cause performance issues.
However, that alone is not a factor: the length of the expression, the number of datapoints or rows and columns displayed, chart conditionals if there are any, variables and their contents, extensions, themes...
But again,
By answering these types of questions you will be more informed as to know what could be the issue or issues causing that delay.
Yes, I have used variables in expressions which are holding in master flat file.
Please find my inline comments and advise
Looks like it is development related, so making charts lighter the app should load faster, because when all objects are removed, even if it uses 3GB in disk, it is loading fast.
It is difficult to go ahead with any further suggestion without knowing the requirements and the data model, as well as the CPU/RAM/Windows data to be able to measure how well each object behaves.
In general, Pick/Match functions can be replaced by flags in the script. The reload time will be longer but the UI will be lighter.