Qlik Community

New to Qlik Sense

Discussion board where members can get started with Qlik Sense.


Typical ODAG response times and performance

Hi all,
since I am trying to optimize the performance of a Qlik Sense detail dashboard which uses ODAG, I would like to know what is the mean timescale to open (in front-end) a detail table which contains 54 fields and has a total of 2 millions of records (in the data model, the structure has 222 fields, so we take about 25% of them in the sheet object).

At the moment, the time which is necessary to show all the records is about 50 seconds.

We tried to improve the performance reducing calculations at front end as much as possible and, at the same time, improving the model associations with respect to the front-end ones.

As a matter of fact, the number of fields reported in the detail table is big, but due to business requirements we cannot reduce it more.

The server where Qlik Sense Enterprise runs has 512 GB of RAM and 40 GB of free disk space, while the app occupies about 140 MB.

Do you have any suggestion to reduce the opening times and also the response times?
Thank you in advance.


1 Reply

Re: Typical ODAG response times and performance

When you say open, do you mean the app has already been created and reloaded? In other words,  after the user clicks the button to open the app it takes 50 seconds? 

If that is the case, there isn't anything ODAG related here, it is purely the app performance. Qlik is not particularly great for displaying that amount of data at a time in a chart. It is compared to other tools, but you won't find sub 10 second performance loading 2M records. I would suggest putting a calculation condition on the table object itself so it doesn't render until the user proceeds to make additional selections within the detail app, making the data in the table chart smaller. This can have dramatic effects, reducing loading time into your desired threshold. Which I would argue makes sense, since a user can't make much of anything when given that much data at once.


Blog: WhereClause   Twitter: @treysmithdev