Maximizing HyperServer Scalability

As we already know, any HyperServer cluster consists of several Nodes running concurrently in operating system process space. For each HyperServer instance the number of active Nodes is determined by configuration and the actual traffic.

Starting with build 1608 you can configure HyperServer to run hundreds or even a few thousands Nodes. This means that you can have hundreds of Nodes running under a single HyperServer instance without facing any adverse effects on the system. Something that wasn't possible in previous HyperServer builds.

That said, it must be kept in mind that maximum number of Nodes (max_nodes parameter) must be increased with caution. More Nodes doesn't always mean better performance or better scalability. On the contrary, unnecessary Nodes can put unwanted load on the system and consume valuable system resources such as CPU, memory and threads. So, increase number of Nodes when it is actually needed. The first scenario that comes to mind is a HyperServer instance that runs multiple HyperServer Applications. For instance, if your HyperServer instance runs 20 types of different application and you want at least 10 Nodes per application, it is obvious that number of active Nodes will easily exceed 200.

It is also important to know that increasing number of Nodes won't automatically make your application more scalable. In order to get benefit from HyperServer, your application must be designed to cope with increased load in the first place. I.e., regardless of number of sessions your application and its database back-end must also be scalable. For example, if there's a bottleneck in your database back-end, your application will also slow down and stop responding when incoming load reaches a certain level. So it is very important that your application is designed by taking all scalability rules into consideration.

There are some steps that, if followed, will help maximize the number of concurrent Nodes in your HyperServer cluster and deal with scenarios mentioned above. These steps are especially important when your server hosts multiple instances of HyperServer and each HyperServer instance will spawn many Nodes. There are extreme scenarios where you need to host multiple instances of HyperServer in the same server and each instance serves multiple HyperServer applications. This may lead to a situation where hundreds (or even thousands) of HyperServer Nodes may coexist within the same server. The steps below will help you make sure your cluster won't suffer from OS imposed limits under such scenarios. It is needless to say that the primary step is to make sure that your server is equipped with enough hardware resources such as CPU cores, physical memory and storage space.

1

Create your Node applications as console applications (Or convert your existing Nodes to console applications)

Under Windows there's an OS imposed limit named Desktop Heap. Compiling your apps as Console Applications will make sure that this limit will never be reached and your HyperServer instance can spawn hundreds (or even thousands) of Nodes without hitting the Desktop Heap limit.

Main article: https://unigui.com/doc/online_help/compiling-nodes-as-console-app.htm

2

Use Named Pipe transport instead of HTTP transport (Currently available for Windows)

Another system imposed limit/resource is the TCP dynamic port range. If too many live TCP connections are created and destroyed in a certain period of time, there's a chance your system will face a condition named "port exhaustion". This problem can be partly resolved by increasing the dynamic port range, but it won't completely eradicate the problem, as you may still face "port exhaustion" under heavy traffic.

There is also another TCP-related limit. Port numbers are 16-bit words by design. This means that max port number cannot exceed 65535. So if you have many HyperServer instances in the same server and each instance must serve hundreds of Nodes you may have difficulty finding a unique port range to assign to each instance. Since HTTP transport channels are implemented on top of TCP, all above disadvantages also apply to HTTP transport channels which HyperServer uses by default.

Named pipes don't suffer from such limits. The number of named pipe servers and clients is limited by system resources only. So you can take advantage of better scalability by switching to named pipe transport channels, which can be configured in the HyperServer CFG file.

Related articles:

  • https://unigui.com/doc/online_help/more-on-transport-channels.htm

  • https://unigui.com/doc/online_help/additional-network-settings.htm

3

Use custom Windows accounts and separate pools

If you plan to host multiple HyperServer instances on the same PC, instead of using the built-in LocalSystem account, create and use custom Windows accounts for each instance. Please note that these accounts must be created with administrative privileges.

If you are using IIS as deployment method also make sure you use a different pool for each HyperServer instance.

Follow instructions in section HyperServer ISAPI Module Mode to properly configure ISAPI pools and applications: https://unigui.com/doc/online_help/hyperserver-isapi-module-mode.htm

If you are using Windows Service as deployment method you can also change the default account and use a custom Windows account with administrative privileges.

4

(Optional) Install uniGUI HyperServer configuration tool on all servers in the cluster

This step is optional. If your HyperServer instance is not a master HyperServer —and— it is using named pipe transports —and— all of your Nodes are compiled as console applications you can skip this step.

We have already discussed two different OS-imposed limits: Desktop Heap and the dynamic port range (which may lead to port exhaustion).

This tool is designed to perform modifications in system settings, so both limits will be increased to a certain amount.

In short:

  • This tool will increase dynamic port range limit from 16384 to 32768 which will highly decrease chance of facing condition named "port exhaustion". (This only applies to HTTP transport channels.)

  • This tool will also increase Desktop Heap limit from

Note: This tool can be downloaded from customer portal.

Related articles:

  • https://unigui.com/doc/online_help/additional-network-settings.htm

  • https://unigui.com/doc/online_help/hyperserver-system-configurati.htm