Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi All,
I had this question being asked from my management over and over....
How response time will be better from physical than VM for end users using wlikview apps.
a lot of answers if you can try to search in this forum, just two link...
Lately, in my experience, I have seen less performance degradation when deploying QlikView on a vm environment, instead of on physical hardware. Depending on configurations (optimizations), using contemporary virtualization software (i.e. not 3 versions prior), and performance tuning the QlikView environment will all contribute to great performance to end users on a vm platform.
Hope this Helps.
~Greg
So What Yo uare saying that , staying on VM is not big problem?
Yes. Another option, you can consider virtualizing specific components, example: QlikView Publisher, Web Service, and place the QlikView Server on dedicated hardware. Virtual deployment of Qlik has seen great performance improvements in the past few years. I strongly and respectfully suggest dedicating a vm instance to QlikView alone...if you need to virtualize...as I have learned, QlikView will cannibalize the RAM and CPU on a machine...in a vm instance where QlikView is installed with another application...this can have undesired performance results.
Hope this Helps.
~Greg
It might also be worth pointing out that Qvs is not the only service that is worth considering moving to a separate machine. Publisher, or the Distribution Service, is not seldom another reason for resource congestion. When a reload task is run, QDS will spawn a QVB process, which in all intents and purposes is a QlikView core (Qv, Qvs), which will do the reload. This process, like the Qvs, has the potential to use a lot of resources. It is good to keep this in mind, since Qvs and QDS will fight over resources if they are executing heavily at the same time.
So, a real distributed deployment might have Qvs services on separate machines and QDS on separate as well. You usually refer to this as front-end and back-end, for obvious reasons.