QV10 server performance issues

[alal]

We are mature users of QV and upgraded to QV10 SR4 in february. At the same time, we split our Reload and Presentation servers (2 separate machines now) and also upgraded them to 2 x Six Core (Intel X5690 @ 3.47ghz each - Hyperthreading disabled). 

Our Problem: I am consistently finding that users complain about server performance. even simple objects like a multi box.

I find a few reasons for this:

1) Early morning, When a document is loaded to memory for the first time. This definitely maxxes out all our processors and for some documents, this can be a 1 minute stretch. During this time, other users struggle to get any response on any other applications.

Now we could say-The document is big / Preload the document into memory etc. But should qlikview not manage traffic better and keep CPU aside for user activity?

2) Delta reloads - People want upto-date information, so we reload some documents every 10 minutes / others every half hour and allow multiple copies in memory. Is there any tools for closer/better memory and session management? Faster recyciling of refreshed documents etc. Can't be good to have so many multiple versions in memory.

3) I cannot be sure, but I think every day, at least once, the QV Presentation server (QVS) simply gives up and needs a restart. At this point, I find the CPUs are completely maxxed out and RAM is approximately 75%.

Perhaps there are settings which will improve this performance, if so, please let me know urgently. Open to suggestions.

But currently it feels like QV needs to make some simple adjustments in threading architecture.

Atul

[Sebastian_Fredenberg]

Hi,

Going into specifics is hard as much depends on application design and server setup. First of all I advice you to take a look at our Quick Tips found under "Documents" as they cover general advice regarding best performance.

If all users access the document at approximately the same time, and before it has been fully loaded into memory, they will likely experience delays. As for maxing out CPU during that period I would guess that the document contains objects that require heavy calculations. If all CPU:s are required for these calculations, then concurrent user activity will be delayed during this period.

As one part of accessing the document is loading it into memory, it should certainly help by preloading it into RAM, in that case the time and resources needed for that operation can be disregarded for the first real users accessing the application.

As for the delta reloads, as far as the memory permits there is no harm in having multiple copies of the same document in memory. It all depends on how many documents will be in memory, but this is the way to handle it if the documents needs to be updated that often. By always logging out from the applications when not actively using them, the amount of different copies should be lowered as documents without active sessions will be removed from RAM. Note that Qlikview will by default use up to 70% of available memory. The memory is of course used for the document itself, but this is usually a minor part compaired to the rest which will be used as cache. The cache part is a moving part of RAM so often there is room for more copies even if it looks like QlikView have consumed 70% RAM already.

Lastly, does the QVS restart by itself or is this done manually due to it maxing out CPU?

In either case, it is good to try and find out the reason for this. First of all, check the eventlogs for reasons. Secondly, another good way of troubleshooting is setting up performance counters and let windows gather data from all running processes. These logfiles can then be read into qlikview to analyse the server performance. Our performance testing tool (also found under documents) contain preset performance counters and also a qlikview application for analysing these, however they require other files as well to work so it will not work out of the box with just performance counter logs.

Regards

Scalability Center