I am having a performance issue with a chart in my app. I am attempting to display it as a table that consists of 11 dimensions and two expressions, with its intended use as a list of our clients and their billing YTD and LYTD. I am using set analysis in my expressions so no horrible nested if statements there.
The main issue is with response times whilst scrolling through the table view the IE plugin. We have set up a desktop shortcut that automatically launches IE and navigates to the required app. We run Windows 7 machines with 3GB of RAM and i5 processors neither of which are being maxed out during use. We are running Version 12 of Qlikview, and Version 11 of IE.
How does the sever behaves during those requests? Do you see higher or unexpected use of CPU or RAM when users open that document and scroll that table? Is it any better if they use Ajax instead of IE Plugin? And version 12.00 SRx or 12.10? The latter is known to provide several performance enhancements.
Thanks for the speedy response. The server is not showing any abnormal performance when the app is being used. The Ajax option is a no go as when the app is put on general release to the business it will have to be deployed through the IE plugin. We are running Qlikview version 12.0.20400.0. If we have to upgrade we can do but ideally I'd like to solve the issue without having to do this.
What is baffling me is that the rest of the app is very responsive, and at the absolute maximum the table is attempting to show 7000 rows which is nothing really. The whole app is only 26mb and the object is only 700k so memory doesn't appear to be the issue here.
Indeed it seems like a product related issue, I don't have all the release notes at hand but it might be worth checking if this was a known issue and has been addressed in a newer release.
Another two things I would do to try and isolate the issue:
Empty QVW with only datamodel but no other chart or object (not hidden) just the one with issues
Still using Ajax to test whether the object responds in the same fashion or not. If it does, the object is likely the issue (i.e.: some expression, color expression or something). If it does not, then is the client which is having the issue (IE Plugin) in which case I would test using QlikView Desktop and QVP instead of opening the document locally.
Again unfortunately we do not have a license for QVP so not an option.
There is no clever formatting going on i.e. changing colours dynamically or anything of that ilk. When I open up the app on the desktop version I do not see the performance issues but my development box is geared higher than the normal users.
As for getting QlikView desktop put on all the machines I could try but I feel I'm going to run into resistance on that from the IT lot.
How come you cannot use QVP? I don't know of any license avoiding it and, by the way, if you are using Plugin, you are using QVP (meaning direct connection to QVS bypassing QVWS).
I'm not asking to deploy to every computer, I'm trying to find out where the issue is, so you only need to use Ajax once or install QlikView Desktop once to see whether or not it behaves the same in all possible ways of consuming the app.
I guess it is very likely the same thing Qlik Support will ask you to do to see if it is development related or product related.
I think the misunderstanding is on my end, I thought you meant QlikView Publisher when you used the acronym QVP. We are currently in the process of installing the new QlikView release 12.10 so I shall see if that has any impact.
I see what you mean now re: QlikView Desktop and Ajax and once the new version is installed on the server I shall see what impact that has on the problem.