Section Access causes slow document delivery to browser

[Anonymous]

Our users are finding that documents load very slowly in their browser when we have Data Reduction based on Section Access.

Testing two versions of the same document, one with a Section Access; section and the other without, the Section Access version takes 5-6 time as as long to display in the users browser. This is true for ACCESS = USER, where users will see reduced data and ACCESS = ADMIN where users will see all data.

The document without Section Access delivers ALL data to the user and this performs very quickly. Why should it take significantly longer to deliver ALL data to ADMIN or even a subset of data to USER in a Section Access setup ?

Has anyone else encountered this sever to browser performacne problem. I just want to get a feel for everyone's performance experience of section access.

There is an unresolved post http://community.qlik.com/message/210111#210111 which also comments on this.

Any insight/anecdotes appreciated.

[IAMDV]

Hi,

In my head this is completely normal behaviour when you have huge document with Section Access.  This will take more time than loading full data. Think of Section Access as pre-defined selection states and locking these selected fields after selections within your model. Before you understand how Section Access is logically processed please check how QlikView works. Again this may not be physical processing but this is just logical processing.

The data records are read into the memory, so that all the processing of data may be done through memory. I am sure you know this bit. QlikView treats all the data as Data Element Type (Columns / Fields) and Data Element Values (Values / Records). So each different data element value of each data element type is assigned a binary code and the data records are stored in binary-coded form and they are also sorted. By using the binary coding, very quick searches can be done on the tables. Also, QlikView removes the redundant information information and reduces the amount of data. However, the redundant information in stored as seperately with the frequencies for each unique data element value and across each data element type. When user makes a selection on data element values then the implied selection (possible values) are kept track seperately to present them to the user. By this process QlikView can perform rapid linear searches.

Now, once you have loaded the full data then you are performing additional selections (For Section Access Data Reduction) within your model and this depends cardinality of your data or number of distinct values within your data reduction field. So if you have many distinct values and with large Section Access table then it would take some time before you open the document. However, if you are opening as Admin then you don't have the additional step and you are just getting the full data. To improve the performance.... I'd suggest you to check the data reduction field. If this is a unique key/ key field then check if it's hashed key and I don't recommend using the hashed key to redcuce the data. And also please stay way from using the concatenated fileds directly on Section Access data reduction...rather work through your script assign a key with natural numbers where possible and this will be efficient. Not just QlikView but your memory & processor have many small algorthims which try to guess your selection & calculation pattern.

All this is... just my experience & observation and this is not official documentation but hopefully this gives you some insight.

Good luck!

Cheers,

DV

www.QlikShare.com

[IAMDV]

Is this resolved? Managed to get it to work?

Thanks,

DV

[Anonymous · Accepted solution]

Well this was a bit of an ordeal.

I turns out our server was not set up correctly within our netwowk/active directory infrastructure.

AD did not know where our server was physically located and so did not know which AD replication server to use to fulfill AD requests for users requesting access to the server.

This could at times lead to huge delays as these requests bounced around the network.

One thing that helped us identify this was adding USERID to the section access rather than NTNAME. This forced the QlikView logon dialog box to be displayed prompting the user for their QlikView User ID. This showed that the delay occured BEFORE this dialog box and therefore was not associated with the delivery of the report and the data by the QlikView Srrver. It must be associated with something before that, namely the lookup of the user in Active Directory.