Load Balancing Considerations

Overview

To support high volume deployments with (typically) hundreds of named users, the architecture of Intelledox Infiniti scales Horizontally across the web server tier. Each web server will behave as a single logical instance to the user through the use of load balancing technologies, such as F5.

Infiniti works with any load balancer that supports ASP.NET applications running within an IIS environment, such as Microsoft IIS Application Request Routing (ARR), F5 and other third party load balancers.

Before setting up Load Balancing, it's important to understand contributing factors that relate to load on servers, and how Infiniti manages session data.

How Infiniti stores user sessions

Infiniti stores user sessions (and data) in IIS App Pool Memory, unless SQL Server Session state is enabled then the session is stored within the configured storage provider, e.g: Infiniti Database. The downside to storing session data in the Infiniti Database is slow performance, as with typical failover db clusters, the session data needs to be replicated across the db cluster which in-turn impacts the user experience.

The session cookie is stored within the client browser. Infiniti will make keep alive calls to make sure that it doesn't expire, and also to ensure that the session on the server isn't removed.

Sticky sessions keep requests going to the same server that has the wizard in memory session state. Without sticky sessions, SQL Server session state is needed so that IIS can handle the request from any of the web servers.

Factors that can impact performance

• Chatty Forms - Extensive data source calls, multiple repeating sections with formulas and references in the form that prepopulate and validate data;
• Large Answer Files - How big is the AnswerFile, are there a lot of attachments being uploaded by users and services, like documents and images;
• Concurrent users - It’s important to note here that you can have 1000 users all on a form at the same time, and use zero server resources. Resources are required when a user triggers a post back, e.g: a Next Page event, data source lookup, form submission or Document Generation. A concurrent user in this (Infiniti) case, is how many users are all actively triggering post backs at the same time;
• Document Generation - How many documents are being generated and size (number of pages, images and repeating sections) of each document; and
• Actions - Number and size of Actions that are being triggered during Generation.

Configuration options

Infiniti sessions are handled by .Net session providers referenced within Infiniti, which store session data in Web Server memory. Storing session data in memory is prone to being lost when auto scaling solutions scale down, due to low usage volumes.

To combat session loss, you need to make sure you configure the following in your Load Balancer:

• Sticky Sessions
• Cookie Persistence

In the past, setting both options has not always worked due to various factors, but predominately due to the session being destroyed by the scale out solution, when scaling down. The load balancer in this case, will do its best to retain the session by knowing which WFE has the active session (via cookie persistence), but at the end of the day if the session is destroyed and not retained, your load balancer can't help. However, you have the options to store session data elsewhere.

• IIS App Pool - By Default - Managed on Web Server by using tools like F5
  OR
• Database - Using SQL Server Session State, to store sessions in a central location, for a scale out Topology

These options are the "out of the box", you can build your own providers to override this functionality to store session data in new ways.

📘

SQL Server Session State

"The downside to storing session data in the Infiniti Database is slow performance, as with typical failover db clusters, the session data needs to be replicated across the db cluster which in-turn impacts the user experience."

What’s the best configuration for you?

Best practice is to build your solutions within the Development environments first, before configuration of load balancing. Minimum server specs are suggested for your initial Dev environment setup and should be scaled up depending on usage and requirements of the solution, as there are many factors that can impact these requirements.

This is where you will get a feel for how large user session data will be and how chatty your forms are, then use this information for what will be required in Production and even if load balancing is required in the first place.

Rule of thumb for scaling resources

• Higher document generation and form submission rates increase load on CPU and network.
  

• Higher user loads increase consumption of RAM.
  

As an example, IX Transform (our Azure SaaS instance) has 1300 users and anywhere between 30-200 concurrent users, and is setup on the Azure S2 band which scales Horizontally and Vertically to S3 if required. Keeping in mind that these resources are only used by the Infiniti application, and do not need to take OS resource consumption and other processes into consideration.

Issues after enabling Load Balancing

📘

Users are dropping out and returning to the home page (F5)

Make sure you have turned on Sticky Sessions together with the property called Cookie Persistence.