Skip to main content

Qlik Sense Enterprise on Windows on-premises

You can configure a Qlik Sense Enterprise on Windows deployment to meet the specific needs of your organization. As your requirements for performance and scalability increase, so too will the size of your deployment.

The following terms are used in the deployment scenarios:

  • Central node: the central point for managing all nodes in a site.
  • Failover candidate node: a redundant node that becomes the central node if the original central node fails.
  • Scheduler or Reload node: reloads apps on a schedule, but does not serve content to users.
  • Consumer node: serves apps to users, but is not used to create, process, or reload data.
  • Development node: allows users to create and reload new apps, but does not serve normal consumer traffic.
  • Proxy node: provides load balancing of user traffic to other nodes but does not contain a Qlik Sense Engine Service (QES).
Note: An alternative to using a proxy node is to have a proxy installed on each consumer node and balance the traffic using a hardware load balancer.

Deployment scenarios

This section provides four deployment scenarios of Qlik Sense Enterprise on Windows deployments. The deployments described here are examples of a small, medium, large, and extra-large Qlik Sense Enterprise on Windows scenarios. These examples provide an approximation of the type of workload a particular deployment might need to handle. The figures are not intended to set a minimum or maximum limit on your deployment.

If you expect to have performance demands higher than any of the figures below (such as more reloads or apps) then contact your Qlik partner and perform a full sizing exercise. For more general scalability and performance information, see Performance and QMC performance - best practices.

The following table provides some basic assumptions for each type of deployment scenario:

  Single-node (small) Multi-node (medium) Multi-node (large) Multi-node (extra-large)
Apps 50 100 1000 1000
Active apps per day 25 50 125 125
Total users (from UDC) 500 1000 50000 50000
Concurrent users (equals active users within the same hour) 50 100 500 1000
Maximum concurrent users in the QMC 2 2 5 10

Average app size (in gigabytes)

 

0.1 0.1 0.1 0.1
Maximum app size (in gigabytes) 1 2 5 5
Content creation (objects per hour) 20 40 50 50
Reloads per hour 10 20 400 400
Note:  The difference between a large and extra-large deployment in our examples is the number of concurrent users.

Single-node (small)

The following deployment example shows a Qlik Sense Enterprise on Windows single-node site.

In a single-node site, the Qlik Sense services are all running on the same node.

  • Qlik Sense Repository Service

    There is only one instance of the Qlik Sense Repository Service (QRS) running, and it has direct access to the central repository database.

  • Qlik Sense Scheduler Service

    The Qlik Sense Scheduler Service (QSS) acts as both master and slave.

This kind of deployment works best in a single time zone, where data reloads can be done at night.

Multi-node (medium)

The following deployment example shows a medium-size, multi-node Qlik Sense Enterprise on Windows production deployment comprising three nodes:

  • One central node/reload node on which the Qlik services are running.
  • Two consumer nodes to load balance user demand.

In this configuration, the central repository database, the file share, and the other Qlik Sense services are running on the central node. The two consumer nodes handle app consumption.

Multi-node (large)

The following deployment example shows a large, multi-node Qlik Sense production deployment. A deployment like this provides the ability to scale up app reloads and user load. This deployment consists of the following nodes:

  • Central node/reload node to handle the services
  • Failover canadidate node to handle the services if the central node fails.
  • Four consumer nodes to load balance user demand.
  • One developer node for app development.
  • The repository database (PostgreSQL) and the file share are installed on separate, dedicated servers.

The central node and failover node must have all services installed. Configure the proxy service on consumer nodes to handle user traffic, and on both the central and failover nodes to handle admin traffic.

Note: The Qlik services on both central and failover nodes are always active.

Multi-node (extra large)

The following deployment example shows an extra large, multi-node Qlik Sense production deployment consisting of seven consumer nodes providing the ability to scale up app reloads and user load. Groups of consumer nodes are dedicated to different size apps. Each consumer node can be configured with security and custom load balancing rules to restrict the size of the apps they can serve.

To ensure that the system can cope with the load, you can pre-load some apps in memory. For example, you could pre-load all medium and large sized apps, ensuring that they can be loaded in less than two seconds, even during peak hours. For more information on pre-loading apps, see App preload - a cache warmer.

Note: With very large deployments, development of applications can be resource intensive. It may therefore be appropriate to have a separate deployment dedicated to app development. If you prefer to keep developer and consumer nodes in the same deployment, ensure the resource limits are suitable for the developer nodes. This includes reload time, hyper cube timeout, and amount of RAM.

This deployment consists of the following nodes:

  • Active central node/reload node to handle the services.
  • Failover candidate node to handle the services if the central node fails.
  • Seven consumer nodes with node clusters dedicated to app size.
  • Two developer nodes for app development.
  • The repository database (PostgreSQL) and the file share are installed on separate, dedicated servers.

The central node and failover node must have all services installed. Configure the proxy service on consumer nodes to handle user traffic, and on both the central and failover nodes to handle admin traffic.

Note: The Qlik services on both central and failover nodes are always active.