Gizmox > Platform > Scalability and Deployment Economy

Scalability and Deployment Economy

One of the most important enterprise tests of technology qualification is scalability. The fact that Visual WebGui is a server centric architecture makes it far more curtail to explain why and how Visual WebGui solutions are scaled.

Scalability Approaches

When approaching to horizontally scale stateful web applications, the following 3 major load balancing options are available which are intended to increase the availability and the concurrent capacity to serve large number of users:

  • STATIC LOAD BALANCING: IP/Machine sticky – each server is responsible to serve a pre defined group of machines.
    • Pros:
      • There is no need to plan the development process to support this approach or to have any sort of specific server side support.
    • Cons:
      • No redundancy; upon server crash a group of workstations will not be able to continue working until the configuration is manually changed.
      • Can easily create a non balanced load on the servers.
      • Increasing or decreasing the number of clients, requires re-configuring the load balancer manually.
         

      Static Load Balancing - Visual WebGui Scalability
       
  • DYNAMIC SESSION BASED: Session sticky – the static link between a workstation and a server is done upon connection establishment; in this option, the load balancing device selects the most available server and connects the client to it. Once the connection is established, the client will be working against the assigned server until disconnected.
    • Pros:
      • There is no need to plan the development process to support this approach or to have any sort of specific server side support.
      • Increasing or decreasing the number of clients does not require re-configuring the load balancer manually and will take effect right after the next connection establishment.


         
    • Cons:
      • No full redundancy; upon server crash a group of workstations will be disconnected and will require reconnecting the server farm.
      • Can create unbalanced load on the servers - the load balancing mechanism is based on the moment of when the load balancer device performs the load test. This fact can create severe non-balanced situations.
         

      Dynamic Session Based Load Balancing - Visual WebGui Scalability
       
  • FULLY DYNAMIC: Call based sticky – the load balancer device has the freedom to route each request of whatever client to the most available server that exists at this moment.
    • Pros:
      • Fully dynamic routing; has the potential to reach truly balance of load on the servers, increase the availability and decrease the response times of the system.
      • Fully redundant, the most severe situation in this case can cause a single request to fail due to server crash, however, the recovery is immediate and the next request will be routed to the next available server.
      • Increasing or decreasing the number of clients does not require re-configuring the load balancer manually and will take effect immediately.
      • Due to the session persistency of this solution, session timeout is not a must and can theoretically persist forever. In addition, sessions can be recovered and reconnected to after server crash or any kind of restart (IIS reset or machine reset).
    • Cons:
      • In many cases this option affects the development process and depends very much on the readiness of the infrastructure in use.
      • The solution can affect the performance.
         
      Full Dynamic Load Balancing - Visual WebGui Scalability
       

If it was possible to easily overcome the development process barrier it was quite obvious that given the above options, we would choose the third one (Call based sticky). Note that the performance issues are thoroughly solved by using very strong state servers (normally some SQL/Oracle/DB2 cluster servers) and high speed communication servers’ farm.

State Serialization is the way to store a floating session on a state server which can be accessed from multiple servers simultaneously and provide the last call based stickiness.

Visual WebGui Scalability Options

With “VWG Cluster Server extension” installed on the server, Visual WebGui is responsible to serialize the entire UI model and store it on a state server (exactly like ASP.NET). In addition, any object which can be serialized and contains no non-serialize-able members will be automatically serialized as well due to a generic serialization forcing mechanism.

Latency issues are commonly solved by strong cluster DB servers (as mentioned above); however, Visual WebGui optimized the state size to the minimal amount of data in order to require less transportation to the DB and back.

Configuring Visual WebGui application to use DB state server is done using the same “sessionState” configuration node as in ASP.NET:

<configuration>
<
system.web>
    <
sessionState mode="SQLServer" sqlConnectionString="data source=server_name;user id=user_id;password=password" stateNetworkTimeout="15" />
  </system.web>
</
configuration>

Visual WebGui is Scalable

Upon decision, Visual WebGui can support all type of horizontally scaling to a web servers’ farm.  The most dynamic and recommended scaling option is the call based stickiness scalability and is fully supported by the “VWG Cluster Server”.

The “VWG Cluster Server" extension provides a complete solution for availability and redundancy using a state server.

The methodology of work with this kind of scalability is identical to ASP.NET, in addition, Visual WebGui provides a generic mechanism forcing objects to serialize whenever they do not contain non-serialize-able members (i.e. BitVector).

Next >>