Reloading document in QVMC while users in it on AccessPoint

[stevelord]

Hi, I have a document reloading in QVMC and I expect when it finishes, end users will have their page reloaded.  However, the document is taking longer than normal to reload - does the presence of users on a document in AccessPoint affect its ability to reload on the server? QV11.2 SR12

I had been under the impression the end users were working from a copy in the cache/physical memory, and that the document being reloaded by the server was independent of that and simply pushed back into the cache after it was reloaded.

PS> I know it's not good practice to reload stuff while people are on, just we were getting a no connection issue likely due to documents recently got a lot bigger even though server memory/processes remained the same.  In an effort to optimize, I went through some load scripts and added 'distinct' to ones recently determined to have many duplicate rows - to hopefully reduce size of tables in the background.  I also set compression to None as I read that helps with saving and loading times.  Our hard disk space is fine, the RAM and CPU usage are getting pushed hard.  Data migration happening in a couple of months and likely have to hang in there until after that.  (Stuff I read in other community posts about optimizing.)

[rwunderlich · Accepted solution]

Users accessing a document has no direct effect on the performance of a reload. As you stated, the reload is working on a separate copy from the users.

There may be an indirect effect on overall machine resources that could make the reload longer.  That is, users using RAM and CPU would make less of those resources available than if the reload was running off-shift.

-Rob

http://masterssummit.com

http://qlikviewcookbook.com

[stevelord]

Thanks for confirming my understanding of that.

I've discovered a screwy address table where 900k users have 21 million addresses instead of just their most current address record.  I know qv dedupes records on the front end, but I'm confident the act of suppressing 20 million rows from the front end objects had to be hurting something too.   (Our company was joined with some others that our parent company acquired and now we're finding out how many times we can double our stored data without doubling server resources.   They've called our server tiny, so confident it'll get a boost once integration activity is further along.)