uniGUI version 1.50.0 introduces uniGUI HyperServer which primarily is designed to radically improve availability, stability and scalability of uniGUI applications. It also introduces other important features such as allowing to update applications remotely without a need to stop the application server.

What is HyperServer?

uniGUI HyperServer is a new server archirecture designed to highly improve uniGUI applications' availability, stability and specifically scalability. This goal is achieved by applying industry's known and widely used techniques such as load balancing and process recycling.

A traditional uniGUI application server consists of one single process and multiple threads. The single process can be a uniGUI executable or an ISAPI or Apache worker process. In all cases all sessions reside inside a single process and several threads in same process are used to handle incoming requests.

uniGUI HyperServer changes above model and turns into a multi-process multi-threaded model. In this new model several worker processes are spawned to serve same web application. Sessions will be divided among worker processes and based on the configuration you may have multiple worker processes for same uniGUI application. Worker processes are managed and orchestrated by another process which is actually the HyperServer itself. The HyperServer will be the main entry point for all incoming requests. HyperServer will take all requests and distribute them among worker processes. HyperServer has also the responsibility to spawn new worker processes when needed and recycle them as soon as they are purged. Since uniGUI sessions are stateful, another important duty of HyperServer is to direct incoming session requests to the correct worker process which has created that particular session. In HyperServer terminology each worker process is called a Node.

A More In-depth Look at HyperServer

HyperServer is a new server technology specifically designed to radically improve scalability and stability of uniGUI application. The immediate question here is that why we need the HyperServer in the first place?

In order to answer this question first we need to make ourselves familiar with a classical uniGUI application. In a classical uniGUI application a binary is generated by the compiler which is typically a DLL or an executable. This binary file is responsible to act as a server as soon as it is loaded into process memory space. It will run indefinitely until it is manually unloaded by 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 application server binary to stay in memory for an indefinite amount of time. Something that is expected from a robust and stable application server.

Another characteristic of classical application model is that a single process is responsible of creating, holding and serving all sessions. It is similar to putting all eggs in one basket. In this case sessions are eggs and the application server is the basket. There are several weaknesses and disadvantages which can be associated with this model. The most obvious problem is that all active sessions will be discarded as soon as web application server is terminated or restarted. Another problem which can highly affect application stability is bugs and defects in application code. Such bugs can lead to severe memory leaks and other problem which eventually may lead to memory corruption and web application server crash. Problem here is that the cumulative effects of even tiny memory problems can build up overtime and affect the server operation. Since in classical model application server is destined to run for an indefinite amount of time even small issues can become fatal over time. Of course, it is only true for applications which suffer from hidden bugs, memory leaks, pointer issues and other problems which may not be visible to the developer. Some of such issues may be hard to detect and fix if a legacy application code is ported from a desktop VCL application to uniGUI.

It is needless to say that well developed applications which are developed according to common design patterns and well tested against memory issues, leaks and bugs are able to run indefinitely in classical single process application model. uniGUI application servers are known to be quite stable and robust. It is a known fact that many developers has little problem with stability in uniGUI. However, it must be emphasized that while the single process model can be considered as stable for typcial uniGUI applications, same thing can not be said for scalability. Considering the stability, the main problem of developers is that they may face software defects in many levels which may be hard to detect, fix or find a workaround. Let's look a list of such defects:

•Bugs in 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 and etc.)

Some of the above sources can be very rare, such as compiler bugs and Delphi library bugs, we can't deny their existence. Among above bugs only those which may lead to memory leak, memory corruption or deadlock in code can be harmful for a server application. Most common bugs are those which directly exist in project code. The native nature of Delphi apps make them vulnerable to memory issues and until all those issues are fixed applications can't be accepted as fully stable. The biggest problem  of software development teams, especially big ones, is that they can't always ensure that code of same quality is produced and each new version is defect free. Even the long stress tests may not be enough to detect, isolate and fix and hidden code defects.

In order to deal with above problem we need a server model which can better tolerate application code with bugs. The main trick here is increasing chance of survival of your code in production environment even when it is not ready for the prime-time. HyperServer aims to improve stability when such conditions exist. HyperServer achieves this goal using by implementing different mechanisms. Internal Load Balancing and Node Recycling.  Load balancing will distribute the overall server load between Nodes. Node Recycling will reduce Node life cycle by recycling them based on predefined rules. Recycling will ensure that Nodes will reside in process memory space only for a definite period. Unlike the classical model which keeps application server process in memory indefinitely.

It must be said that in this sense HyperServer should not be considered as a solution to a buggy code or as a tool to deal with memory problems. HyperServer will neither fix your application bugs nor provide a workaround for them. HyperServer's main job is to make sure that the whole application server will not crash as a result of a memory defect or another problem in a Node.

Probably now you are able to figure out that a HyperServer application is divided into two essential parts. First part is the HyperServer executable which is the entry point for your web application. It will serve all incoming requests from the client.Second part of the HyperServer application is a cluster of Nodes.

uniGUI HyperServer

HyperServer and Scalability

One of the biggest concerns of web applications is their ability to scale up. Same is true for uniGUI applications. In fact, scalability can be a bigger concern for uniGUI app, as uniGUI sessions are stateful and keep all state information in the process memory. We may say that classical application model which uses a single process to serve all sessions can scale up to a few hundreds of sessions. It doesn't mean that you can't have thousands of sessions in classical model. Theoretically there is no upper limit to number  of sessions in the classical model as long as your server has enough resources and your application design is inherently scalable. The question here is that is it safe to put 1,000 eggs in a single basket? Obviously, the answer is no. However, everyone seems to agree if we distribute 1,000 eggs among 10 baskets each containing 100 eggs. That's where HyperServer comes to the scene. HyperServer internally divides your application into several Nodes and distributes sessions among those Nodes. Since each Node is a separate process its sessions are isolated from sessions in other Nodes. So any problem in a Node can only affect that Node and its sessions.

The eggs and the basket problem is not the only problem associated with the classical single process application server model. Another problem is that keeping enormous amount of sessions in same process can lead to other problems. One problem is that uniGUI apps are highly multi-threaded application and naturally it needs to use locks to synchronize certain operations. With increased number of sessions such locks can turn into bottlenecks. While in uniGUI we try to use locks as less as possible they are unavoidable.Code locks may also occur in RTL code and other involved 3rd party libraries.

Not only HyperServer can manage a cluster of Nodes inside same server,  but also it can be extended to manage multiple cluster of Nodes on multiple servers. Which means you will be able to run uniGUI applications on a server farm. This will add a new dimension to web apps developed using uniGUI and Delphi.

HyperServer and Remote Deployment

Another exciting new feature which HyperServer adds to uniGUI framework is the ability to remotely deploy new versions of your application without a need to stop your server. So HyperServer is not only about stability and scalability. It is also about continuity and availability of your application server. In a classical single process uniGUI application updating applications is relatively difficult. First, you need to track the proper time where traffic is low and there are few active sessions. Then you need to take down the server which means all active sessions will be discarded. Probably you need to warn application users to logout and wait until update is complete.

With HyperServer above scenario is longer the case. You can upload new version of your application remotely and the rest of job will be done by HyperServer. HyperServer will update Nodes gradually and all new sessions will be redirected to Nodes running new version of your application. Nodes with older versions will be discarded and purged as soon as all their sessions are logged out.

For more information about HyperServer please refer to uniGUI online documents.