When embarking on a QlikView implementation, we don't always have the luxury of being able to design the whole environment and to choose the hardware, operating system, or machines at our disposal. Project history, budget constraints, and growth in the use of QlikView within the organization could all have an impact on the environment we have to work with. Small QlikView deployments will usually perform well on even a fairly modest hardware platform, but for large and growing deployments, care is needed to ensure optimal performance.

QlikView is efficient and fast, but its performance can be compromised by the environment it operates in. Many organizations today have moved to virtualization, often with numerous virtual machines running on the same physical server. QlikView runs in a virtualized environment, but its performance can be adversely affected. While a virtualized development environment is fine, you should consider a physical machine for production.

The choice of hardware can be surprisingly important to QlikView. Fast processors and huge amounts of memory are not necessarily the answer to every performance issue. In fact, the speed at which data can move between memory and processor can be more important—which is obvious, really, considering that QlikView operates in memory. Not all chip sets have the bandwidth to maximize performance.

Performance isn't only about the server, of course. At the presentation level, the choice of browser is also important. This is something you'll have to test for yourself as each QlikView document behaves differently. Qlik supplies an IE plugin in the Server installation package, and this works well. However, if yours is a mixed browser environment or one in which tablets are used, it's worth considering whether to deploy the plugin at all. You could potentially have very different user experiences for the same QlikView document in plugin and nonplugin situations. The plugin takes some of the load off the server and tends to render pages better; so, in an IE-only environment, it is probably the best choice for user experience. The downside is that there's a maintenance implication when new releases of QlikView need to be implemented.

Here's a simple example of the differences in rendering, using rounded corners for a text object, and having shadows around a table object. We will create a text object that says OK and a basic table.

The following image depicts the settings for the text object:

The following image depicts the settings for the table object:

As rendered by the IE plugin, it will look like:

Here's how the object will look as rendered by IE without the plugin:

This simple example demonstrates that even the most basic elements of your environment can and will affect user experience before you even consider processors or memory!

Experimentation is a good thing; so, before choosing whether or not to use the IE plugin, do some experiments with layouts including, if possible, large calculations in the UI.

If you have the opportunity to influence the choice of hardware, consider referring to the whitelist published by Qlik Scalability Centre. This document is updated from time to time and is based on actual customer experiences. It covers processors, memory, architecture, BIOS, and Windows' settings.

Qlik or your partner can help you calculate how much memory you need, but you need to provide some basic pieces of information: a rough estimate of the number of rows, the width of these rows in terms of columns and the width of the columns themselves, the uniqueness of data (timestamps are more unique than dates, for example), and a reasonable estimate of the number of concurrent users. Despite everyone's best efforts, it is still very hard to come up with a precise answer to this question as there are simply too many variables. In fact, the only way to know reasonably accurately how much memory will be required is to create the solution first! This is a classic case of a chicken-and-egg situation, not helped by the fact that you'll almost certainly be creating multiple applications as time goes on.

There is more useful information about optimal server settings at https://community.qlik.com/docs/DOC-2362, covering topics such as hyperthreading, power management, and node interleaving. If you only read one document about settings for optimal performance, be it setting up a new implementation or running an existing one, make it this one.