QlikView and VMWare configurations

QlikView VMWare Configurations

QlikView works really well with virtual environments, but might not deliver its full potential because the way QlikView core architecture works internally with hardware. And as we know it's more memory dependent. Virtual instance of QlikView may not perform well as oppose to standalone instance. The main point is that Qlikview's sometimes poor performance on virtual environments does not inherit from poor Qlikview design, but merely from the fact that the general idea of platform virtualization works in the opposite way of Qlikview architecture. 

Purpose of the virtualization is to share the over-committing resources between multiple guest systems to optimize hardware usage, which does not benefit Qlikview, which needs dedicated CPU and memory resources to deliver the user experience which Qlikview system enables. Essentially virtualization also has a bridge, and subsequent overhead, between the real hardware and the applications, which will not benefit from Qlikview's real-time need of dedicated hardware resources.

In comparatively smaller and environments and test environments QlikView will work fine, but when you need performance virtualization is not an option. While running QlikView in virtual environments make sure CPU is not over committed, resources are not shared and memory ballooning is turned off. Optimize disk usage (defrag!) and use a hyper-visor that is as close to the metal as possible (VMWare ESX for example)

However below are some of the configurations one need to do, to gain optimum performance from the virtual environment.

• Confirm whether the VM is I/O or CPU bound (if CPU is <80% then machine is probably waiting for disk or network activity to complete)

• Most important - be sure the virtual environment that the QVS is running under has DEDICATED resources allocated to it. That means dedicating a set # of CPUs and a set quantity of RAM. Note, this is against the first instinct of your average VMWare administrator. They will want to allow DYNAMIC allocation of CPU power and RAM. This is because they want to maximize the number of virtual instances they can support on a given piece of hardware. This works fine for most applications but not for QlikView because of the way it uses resources. You need to ensure the server administrator understands this and allocates sufficient DEDICATED CPU and RAM to your QlikView instance.

• Always turn off the ballooning driver, if it’s installed. It flushes memory to disk, and disk is really slow compared to real memory. Make sure no swapping occurs at any level.

• Rubber band of memory should be turned off

• Disable CPU over commit

• ESX3.5 is not recommended since its CPU scheduler is really slow. If you create a machine with 4 CPUs, it won’t run (it will stay stopped on CPU level) until there is four free physical cores available at the same time. The more machines on the ESX server, the less chance this happens. Use at least 4.0 U1 but preferably 4.1. If you must use ESX3.5, use single core VMs and scale out.

• Do you need to have serious knowledge about VMWare to be successful? Yes. Use experienced people.

• Bulk I/O – use only when needed. IO is only generated when documents are loaded / saved, but with the structure we use with the QEMC / Publisher in combination with the refresh features, it will become more important.  On a system with lots of IO, enable it. If the document is preloaded in the morning and stays in memory, leave this setting as is. Don’t change unless needed.

• Shared Disk performance.  A VM usually has virtualized Disk I/O because the “Hard Disk” is commonly implemented as a file on the underlying operating system. This can be slow. Using VMware on our laptops is also usually slow because of I/O –not because of shortage of RAM or CPU.

• Disable any Virus Scanner inside the VM

• Defrag the Virtual Disks and the physical disks