To support high volume deployments with (typically) hundreds of named users, the architecture of SmartIQ 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.
SmartIQ 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 SmartIQ manages session data.
SmartIQ stores user sessions (and data) in IIS App Pool Memory.
The session cookie is stored within the client browser. SmartIQ 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.
- 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 (SmartIQ) 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.
SmartIQ sessions are handled by .Net session providers referenced within SmartIQ , 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
This option is "out of the box", you can build your own providers to override this functionality to store session data in new ways.
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.
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 SmartIQ application, and do not need to take OS resource consumption and other processes into consideration.
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.
Updated 8 months ago