Multi node setup or dedicated server for development

[n1ef5ng1]

Hi everyone,

Would like to ask opinions from everyone that are familiar with upgrading of server specs.

We are currently looking in improving the performance of user experience in Qliksense. Our setup currently have 1 server that are for developing, ETL running of schedules and users using the dashboards.

Currently based on the monitoring dashboard, our server are not overload in terms of CPU and Ram usage. However, there are big spikes as ram usage goes up to 80-90% when i start to manually load ETL on development work during office hour (that is where users uses QS accounts). On hours where there isnt any development work and in office hour, our RAM usage is around 40%.

We approached consultants and they feel that there is a need to get another server that does purely for developer works. However i prefer on having the additional server to do multi node setup but could not read much on the benefits. I prefer on the multi node setup as i believe there are higher scalability as compared to having a dedicated server.

Correct me if i am not wrong, with multi node setup , i am able to design where the second server (rim node) can be purely use for development and switch to help on the central node if there is a stoppage of development works etc?.

Hope everyone understand the situation.

Thanks.

[Miguel_Angel_Baeyens]

This summarizes pretty much all:

https://help.qlik.com/en-US/sense/September2018/Subsystems/ManagementConsole/Content/Sense_QMC/confi...

I agree that having an additional node which could be used for production could help in peaks of activity. However, setting up the role of a node as Development has its implications other than performance (like security) and anyway, users directed to such node will be affected as well while performing development activities like reloads.

Have development in a different server and if you want high availability or need more resources, add another node to production, but keep them separate, when possible.