QlikView in Virtual Environments

This is a compilation of inputs gathered about running QlikView in Virtual Environments. It is NOT an official
support paper from QlikTech, nor is any of these official statements from QlikTech, but it is a gathering of
practical inputs from consultants and technical experts.

Running Virtual Servers

First of all, you need to understand why the customer is using virtualization technology.

The typical reasons are the following:

Utilizing the hardware

Memory Sharing
CPU Sharing
Disk Sharing

By sharing hardware, the available power (in terms of memory, CPU and disk) may be more effectively used.
This is a matter of not wasting any available resources.

High Availability (HA)

Technologies such as vMotion which keeps machines in 100% sync

Clustering technologies

HA technologies may be another reason, where the customer uses VM technology to achieve 100% uptime (or
extremely near 100%).

Management

Images can easily be dealt with

Backup/Restore is easier
Snapshoting is a great feature
VM movement

Management is probably one of the key reasons for virtualizing. Handling 100 physical computers over time
requires a lot more effort than doing the same thing with virtual ones. Moving machines from slower hardware
to faster is even possible while the machine is powered on!
Economy/Environment

The power requirements are less

Physical space requirements are less

Power requirements are steadily raising and are becoming a serious problem. With modern servers, its
impossible to utilize an entire rack of 42U because the amount of electricity to the rack is too high.

Bug Tracking / Proof of concept

Run the software on virtual machines for testing purposes

Snapshoting a broken environment to send to support
Debugging and testing

Running the test environment on VMs is an excellent way of increasing productivity among the testers.

Performance degradation in virtual environments

When you have a clear picture of why you virtualize, youd understand that the key reason is almost never
performance. Its almost always about other things.

There is a non-negligible performance impact in migrating from a physical machine to a virtual machine. One
Study found a 40% decrease in capacity for a web application when it was migrated from a physical machine to
a virtual machine. Not surprisingly, there are conflicting studies from VMWare showing a much smaller
capacity decrease on virtual machines. But even VMWare concedes that "performance within 16% of native is
considered to be relatively good.

Is this capacity hit (16-40%) acceptable? Well, it's all context-specific. It depends on the current hardware
utilization; if a server is 90% idle, then virtualization might serve the customer very well. However, if a
server is less than 25% idle, then virtualization will result in a noticeable slow-down for end users. And as
idle time approaches 0%, response times climb through the roof.

It is very important to understand that you WILL see performance degradation running QlikView in a virtual
environment. In some cases that is unacceptable. In other cases this may be acceptable. That is up to you and
your customer to decide.

The bottom line: some of our customers deploy on virtual machines in production and are happy with the
results; customers with more demanding usage patterns, larger data sets and limited hardware resources
should deploy directly on physical machines to maximize capacity and ensure acceptable response times.
Running QlikView on Virtual Servers

So, will QlikView (which is a performance application) work in a VM environment? Well, it depends.

QlikView does officially support Virtual environments; however it is strongly recommended that QlikView
Server is run on a dedicated physical machine. The official QlikTech Support Statement can be found here:

http://vmware.com/files/pdf/isv/QlikTech_Support_Statement.pdf

QlikView is RAM intensive and was designed to run on a dedicated multi-core machine (it also leverages multi-
threaded calculations).

The first question to answer is "How much hardware does the QVS require?" Everybody who's tried to answer
that question knows it can be quite hard. It depends on the document size, the amount of documents,
document structure, number of concurrent sessions, document preloading, caching, response times and so on.

The second consideration to be done is: How much sharing do I want with the other VMs running on the same
hardware? The QVS can eat hardware resources for breakfast, which means it's a rather bad candidate for
sharing resources with others. But again, it depends on the customer requirements. Let's take an example: We
have a QVS working fine on a physical quad core system, it takes 50% cpu ("2 of 4 cores"), 4Gb of memory and
it's response times is less than 0.2 seconds. We have a box with ESX Server, which has 8 cores and 24Gb of
memory. The machine is currently utilized to 25% cpu and 50% memory. Can we move the QVS and keep the
response times? Probably. It will increase the memory footprint on the ESX from 50% (12Gb) to approx 66%
(16Gb), and the cpu from 25% (2 out of 8 cores used) to 50% (4 out of 8 cores used). And still, the numbers I
wrote here isn't really true.. because the ESX does some cool stuff preserving resources such as memory..

In an installation, we might have to throttle the QVS to keep the other systems running fine (which will limit
the QVS), or the other way around, lock the ESX to give some specified amount of resources to the QVS (which
will limit the other machines running on the system). Or allow the system itself to balance the resources.

When virtualizing a large QlikView Server on a host you have to be aware of the following:

It is often not possible to allocate enough CPUs/RAM per machine to satisfy QlikView needs

One-big-machine guest in a VM host does not leave room for several other guests, and therefore
defeats the purpose of virtualization in the first place

Performance will be affected by the added abstraction layer between QlikView and the hardware.
Important settings to be aware of

A general list of rule of thumbs can be found here:

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 its 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 wont 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. Dont 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