Load Balancing And Session State Configuration

Load Balancing And Session State Configuration are techniques for the Application Administrator to divide or distribute the workload evenly across various servers. When multiple servers use this type of environment it is known as Web Farms. So basically farming helps in avoiding overload on a single server thus helps in providing better performance, better resource utilization and maximizes throughput.

Load Balancer

Load Balancer is the single point for handling requests and is the key that decides which request needs to be forwarded to which server in the Web Farm Environment. Every request first arrives at the Load Balancer and then it is the role of the Load Balancer to forward the request to a specific server based on the current load and the state of the server.

In a Web Farm scenario, even if one of the servers stop working or crashes, the application will still work or respond, since other servers are still working, so the only point at which your application can go down is when the Load Balancer goes off.

There are various algorithms to define how the Load Balancer works, like "Round Robin" and "Least Connections" and so on.
For achieving this type of environment we need to take into consideration a few things like Session Management, Cache Management and the most important is the Database clustering (that is not usually taken care of by many). I will elaborate Session Management as keeping the scope defined; I will only be saying what changes you may need to make in your application or how to make your application work in a Load Balanced Environment. The configuration the of the Load Balancer is out of the scope of this article.

There are many tools available in the market for Load Balancing, you just need to do the configuration settings and if your application is ready for this environment, you are ready to go.

Sticky Sessions

So what are Sticky Sessions?

When a client makes a first request to the server, a session is created (by default or usually as In-Proc Sessions) in the server memory for that user, all the subsequent requests use the same session object. Now as I said, the session is created in the memory of the server handling the very first request, and in the Load Balanced environment we have more than one servers serving the requests, so what if the second request goes to another server that does not have that session object in memory, it will create a big mess, so that is the use of Sticky Sessions. To use Sticky Sessions we configure the load balancer to send the request for a specific session to the server that has served the first request. This can create a problem in the Load Balanced environment because it may be possible with Sticky Sessions that some of the servers are fully loaded and some are actually free at that time. But with In-Proc sessions we need to have Sticky Sessions in the load balanced environment.

Serializable Objects

As far as In-Proc Sessions are concerned that are maintained in the server memory, this is not a problem, but if some other technique for Session management is used, like maintaining sessions in SQL Server, then it will be a problem if the Objects that need to be in the Session are not serializable, this is very obvious since they all must know if something needs to travel on the network, if it does then it has to be serializable. Here we will store it on a separate server and all the servers that are part of the Load Balanced environment will access and update the session objects and put it into SQL Server.

Encrypting View State

Encrypting a view state can also create a problem because the encryption logic can vary from machine to machine, for this we need to update the Machine Key in "machine.config", and need to keep it the same on every machine.

Session Management

As of now there are three types of Session Management Techniques that are available:

1. In-Proc
2. SQLServer
3. StateServer

In-Proc Session

For configuring an In-Proc Session just make the following changes to the "Web.config" file:

<sessionState mode="InProc" cookieless="false" timeout="100"/>

In this mode of Session state handling, all the session information is stored within the server memory (In-Memory) managed by an ASP.NET worker thread. This approach is good until the data that is stored in the session is not that heavy, but if you are going to maintain heavy data into it can create a mess for your application then the performance will decrease drastically. Also, the session data stored In-Proc will go off as soon as the application pool restarts.

As I discussed earlier in this article about sticky sessions, if we are using this mode for Session handling then we need to configure Load Balancer (in the case of Web Farms) for sticky sessions, because every server will maintain a session in its memory and if the subsequent request from a client is served by various servers then the application will not behave as it is supposed to. To solve all these problems, we can use SQLServer and StateServer techniques of Session handling.

SQLServer Session

In this mode of session state the session objects are stored into SQL Server instead of a processor or server In-Memory. The "Web.config" changes are as in the following:

<sessionState mode="SQLServer" allowcustomsqldatabase="true" sqlconnectionstring="Data Source=<SERVERNAME>;Initial Catalog=<DATABASENAME>;User ID=<USERID>;Password=<PASSWORD>;" cookieless="false" timeout="100"/>

The benefit of using this technique is that all the data in the session will be stored together in a different location or you can say a centralized location in SQL Server, to get it working we just need to configure the SQLServer to store session data.
While configuring this mode in your application, one needs to consider that all the objects to be stored in a session should be serializable. So if you are currently using an In-Proc session state mode and intend that your application may require to have heavy sessions and you eventually need to shift it to SQLServer or the StateServer, then please take into consideration this "Serialization" issue from now on, because once the application is running and is the production environment, sometimes it is very difficult to make changes to session mode, because of these issues.

Configuring SQLServer to store Session data

Here I will show you how to configure SQLServer for storing session data in a custom database, although we also configure it to save session data in a temporary database, but this database goes off when you restart your SQL Server.
It is very simple by using the command line:

aspnet_regsql -d <SQLDATABASENAME> -S <SQLSERVERNAME> -U <USERNAME> -P <PASSWORD> -ssadd -sstype c

In this command "–d" specifies custom database name, "-S" specifies SQL Server Name, "-U" specifies Username, "-P" specifies Password, "-ssadd" is an option specifying we need to add support for handling session in SQLServer and "-sstype" specifies the type of storage for Session State (if we need a temporary database or a custom database) and "c" represents the custom database.



As soon as you are done with it, you will get a message saying "Finished" with a notification for the settings you need to do in "Web.Config". So here we can see the message saying to configure the sessionState in "Web.Config" to allow session data to be stored in a custom database and we need to specify the connection string for it. You can also check the database created by accessing that server; it will look something like this:



With this we are done with configuring Session State in SQLServer mode.

StateServer Session

In this mode of session state the session objects are stored in a separate server handled by a Windows Service running on that server. The "Web.config" changes are the following:

<sessionState mode="SQLServer" stateConnectionString="tcpip=<IPADDRESSOFTHESERVER>:42424" cookieless="false" timeout="100"/>

The benefit of using this technique is that all the data in the session will be stored together in a different location. In this case the server to be handled by the Windows Service is named "aspnet_state"; this will become the centralized location for session data. To get it working we just need to configure the StateServer to store Session data.

While configuring this mode in your application, one needs to take into consideration that all the objects to be stored in the session should be serializable. So if you are currently using the In-Proc session state mode and intend your application to possibly have heavy sessions and you eventually need to shift it to SQLServer or the StateServer, then please consider this "Serialization" issue, because once the application is running and is in a production environment, sometimes it very difficult to make changes to session mode, because of these issues.

Configuring StateServer to store Session data

Here I will show you how to configure StateServer for storing session data. Press "Windows + R" on your machine where you want to configure it, type in "Services.msc". Here you can see the service "ASP.NET State Service". Just start this service and you are ready to go with StateServer configuration, you can now see this service running in your "Task Manager".



As soon as you are done with it, we are good to go for using this mode of session state.

Hope this article is helpful. I welcome any comments; will try to improve in my next article if something is not good.