Big dashboard, Is it possible to direct sessions to a specific node for the big dashboard?

[jblomqvist]

Hi all,

We have a fairly big dashboard (3.8GB in size) and may have 100 concurrent users.

The app has quite a few CPU intensive expressions, and a big data model behind it. Our developers are working on improving this.

We have other smaller dashboards around 600MB that will be also be live at the same time.

I was thinking, to try and limit the impact of the big app on the other smaller apps, is it a good idea to direct sessions for the big app on to a specific node? I.e. Let one node specifically deal with the big dashboard and the other node can be used for smaller apps.

Is something like this a good idea?

If so, can anyone please show how to configure the QMC like this?

[Levi_Turner]

How many consume nodes do you have? Consume meaning a node with an Engine which delivers app sessions (is load balanced to a virtual proxy?

> is it a good idea to direct sessions for the big app on to a specific node? I.e. Let one node specifically deal with the big dashboard and the other node can be used for smaller apps.

It really depends on what you're trying to solve for. With large(r) applications there can be two obvious problems:

1. The app is large and thus takes a while to load into memory (i.e. second load is appreciably faster than the first load) & user experience is poor due to calculations being uncached
2. The app is large enough to use up a large portion of available resources which cause the entire system to be slow

(2) is basically about resource exhaustion or saturation whereas (1) is about ensuring the app is cached.

If you wanted to solve for (1), then pinning an app to a specific node can be a viable strategy (reference https://support.qlik.com/articles/000050519). Alternatively the app could be cache warmed on each node (reference https://community.qlik.com/t5/Qlik-Sense-Deployment-Management/Best-way-to-pre-cache-large-Qlik-Sens... for an overview of strategies).

For (2) though, app pinning would be needed (or reducing the app's footprint). Because the sheer size of the app as a proportion of available resources makes it so that having the app open on multiple consume nodes is an overall detriment to the performance of the site.