NoMachine Support

Your questions answered

Knowledge Base

Searching in: Articles & FAQs
Filter the search results
Applies to:
Last update:
Searching in: Articles & FAQs
ID: AR02Q01015
Applies to: NX Software
Added on: 2019-02-05
Last update: 2019-03-20
Guidelines for sizing a NoMachine Cloud Server multi-server setup and benchmark tests for v. 6

This article applies to a multi-server infrastructure made of one main Cloud Server and a number of NoMachine servers (child servers) federated under this Cloud Server. The federated servers can be for example Enterprise Desktop or Workstation or Terminal Server or even foreign servers (Unix-based hosts not running NoMachine software). The Cloud Server acts as a gateway to the child servers, the child server type and the session type don't affect results.

Sizing the hardware of your NoMachine server hosts based on benchmarks depends on many variables due to the great variety of systems, hardware, applications and so on. In a multi-server environment, the two main parameters to be taken in account for sizing the Cloud Server host are (i) the number of concurrent accesses and (ii) the method used for dispatching client connections to the child server (direct or tunnel). The first parameter can impact the time necessary to start the session on the child server. The second parameter instead can influence the session performance, if the client connection is tunneled to the child server.

In its default configuration, the Cloud Server dispatches the client connection to the child server, i.e. the communication between the client and the child server happens directly, not through the Cloud Server. Dispatching the client connection is not a resource-intensive operation. However, slowdowns in starting the session on the child server could be perceived by users when there is a peak of accesses to the Cloud Server. 

When the client connection is tunneled by the Cloud Server (which is the fall back method if direct client-child server connection cannot be established), the HW capacity of the Cloud Server becomes more relevant. The client-child server connection is not established directly, but passes through the CS.

For more details about the available methods to dispatch the client connection to the child server, please read here:
https://www.nomachine.com/DT02O00123#3.1.
Red paragraph: Default settings and configurations

About sizing the federated servers, you can find some benchmark results of tests made in our labs here: https://www.nomachine.com/AR02P00966.

 

Some benchmark tests for the multi-server environment

NoMachine Cloud Server
NoMachine Cloud Server (CS) v. 6.4.6 on a Linux host running CentOS Linux release 7.5.1804 (Core) 

Hardware specifications of CS host:

CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz 8 virtual cores
RAM: 20 GB RAM

CS configuration:

Default configuration, CS doesn't use the tunnel method to dispatch connections to child servers.


Child servers
10  NoMachine servers federated under the CS, e.g. Enterprise Desktop.
 
Hardware specifications:

5x CentOS Linux release 7.5.1804 (Core)
CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz 8 virtual cores
RAM: 20 GB

5x
CentOS release 6.10 (Final)
CPU: Intel(R) Xeon(R) CPU W3680  @ 3.33GHz
RAM: 6 GB
 

RAM usage on CS host
RAM:

200 MB (base)
+ 70 MB  for each child server (to keep monitoring the availability of the child server)
+ 70 MB extra for each user for dispatching the connection (this RAM is freed on the CS host once the connection client-child server is established)

Some examples

1) if there are 10 child servers federatd under the CS and 5 users connects at the same time to the CS, the Cloud Server requires:

200 MB (base) + 700 MB (connected servers) + 350 MB (dispatching connections) = 1250 MB additional RAM

2) If there are 500 child servers and 50 users connecting at same time  to the CS, the Cloud Server requires:

200 MB (base) + 35000 MB (connected servers) + 3500 MB (dispatching connections) = 38,7 GB additional RAM

 

Time requested to start the session on the child server could slow down when the number of simultaneous accesses increases

5 users connected to the Cloud Server at the same time
time required to start the session on the child server: about 2-5 seconds

20 users connected to the Cloud Server at the same time
time required to start the session on the child server: about 10-12 seconds

100 users connected to the Cloud Server at the same time:
time required to start the session on the child server: about 20 seconds