A More In-depth Look at HyperServer
In this section we'll take a deeper look at uniGUI HyperServer. We can gather HyperServer features into different categories:
HyperServer and Stability
HyperServer is a new server technology specifically designed to radically improve scalability and stability of uniGUI applications. The immediate question here is: why do we need HyperServer in the first place?
To answer that, first we need to be familiar with a classical uniGUI application. In a classical uniGUI application a binary is generated by the compiler (typically a DLL or an executable). This binary acts as the server as soon as it is loaded into process memory space. It will run indefinitely until it is manually unloaded by a system operator, automatically by the OS, or as a result of a program error which may lead to an application crash. Under ideal conditions one may expect the application server binary to stay in memory indefinitely — something expected from a robust and stable application server.
Another characteristic of the classical application model is that a single process is responsible for creating, holding, and serving all sessions. It is similar to putting all eggs in one basket (sessions are eggs and the application server is the basket). Several weaknesses are associated with this model:
All active sessions are discarded as soon as the web application server is terminated or restarted.
Bugs and defects in application code can lead to severe memory leaks, memory corruption, deadlocks, or crashes. Even tiny issues can accumulate over time and affect server operation.
Such defects may come from:
Bugs in the current project code
Bugs in legacy code ported from an older project
Bugs in third-party libraries
Compiler bugs
Bugs in Delphi standard libraries (RTL, VCL, DB, etc.)
While many uniGUI applications are developed and tested to run indefinitely under the classical single-process model, and uniGUI servers are generally stable and robust, the single-process model has limitations—especially around handling defects that are hard to detect or appear only under production conditions.
HyperServer is not a fix for buggy code; it will not repair memory leaks or logic bugs. Its purpose is to increase the chance of your application surviving in production even when some components have defects. HyperServer improves stability by implementing mechanisms such as:
Internal load balancing — distributing overall server load between Nodes.
Node recycling — reducing Node lifecycle by recycling them based on predefined rules so Nodes only reside in process memory for a definite period.
In this architecture, a HyperServer application is divided into two essential parts:
The HyperServer executable — the entry point that serves incoming client requests.
A cluster of Nodes — worker processes that host application sessions and logic.
HyperServer and Scalability
One of the biggest concerns for web applications is their ability to scale. This is especially important for uniGUI applications because sessions are stateful and keep state in process memory. The classical single-process model can typically scale up to a few hundred sessions, though theoretical limits depend on server resources and application design. The practical question is: is it safe to put 1,000 eggs in a single basket? Usually not.
HyperServer divides your application into multiple Nodes and distributes sessions among them. Since each Node is a separate process, its sessions are isolated from sessions in other Nodes; problems in one Node affect only that Node and its sessions.
Other issues with keeping many sessions in one process include:
Increased multithreading and the need for locks; with more sessions, locks can become bottlenecks.
Locks may exist in application code, RTL, or third-party libraries.
HyperServer can manage a cluster of Nodes inside a single server and can be extended to manage multiple Node clusters across multiple servers — enabling deployment on a server farm and adding a new dimension to uniGUI + Delphi web apps.
HyperServer and Remote Deployment
HyperServer also enables remote deployment of new application versions without stopping the server, improving continuity and availability. In the classical model, updating an application typically requires finding a low-traffic time, taking down the server (discarding active sessions), and asking users to log out.
With HyperServer:
You can upload a new version remotely and HyperServer updates Nodes gradually.
New sessions are redirected to Nodes running the new version.
Nodes with older versions are discarded and purged as soon as all their sessions are logged out.
This allows rolling upgrades with minimal disruption to users.
References:
Developer's Guide > uniGUI HyperServer: https://unigui.com/doc/online_help/hyperserver.htm
Source page: https://unigui.com/doc/online_help/index.html?a-more-in-depth-look-at-hypers.htm