Tuesday, 10 September 2013

Load Balancing + Session State Configuration

It is a technique by which the Application Administrator can divide or distribute the workload evenly across various servers. Multiple Servers when in creates this type of environment 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 maximize the throughput.

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

In Web farm scenario even if one of the server stops working or crashes out, you application will still be working or responding as other servers are 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 the working of Load Balancer like “Round Robin” and “Least Connections” etc.

For achieving this type of environment we need to take care of few things like Session Management, Cache Management and most important is the Database clustering (which is not usually taken care of by many). I will be to elaborating 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 Load Balanced Environment. Configuring Load Balancer is out of the scope of my 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 client makes a first request to the server, session is created (By default or usually used are the In-Proc Sessions) in the server memory for that users, all the subsequent request are using the same session object. Now as I said that the Session is created In-Memory of the server handling the very first request, and in Load Balanced environment we have more than one servers serving the requests, so what if the second request goes to another server which is not having that session object In-Memory, it will create a big mess, so comes the concept of Sticky Sessions. For achieving Sticky Sessions we configure the load balancer to send the request for a particular session to the server which has served the first request. This can create a problem in 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 have to have Sticky Sessions in load balanced environment.

Serializable Objects

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

Encrypting View State

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

Session Management

As of now there are three types of Session Management Techniques which are available:
  1. In-Proc
  2. SQLServer
  3. StateServer


In-Proc Session:

For configuring In-Proc Session just make 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 ASP.NET worker thread. This approach is good till the data which is stored in session is not that heavy, but if you are going to maintain heavy data into it can create a mess for your application, 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 post about sticky sessions, if we are using this mode for Session handling then we have to configure Load Balancer (In case of Web Farms) for sticky sessions, because every server will maintain session in its memory and if the subsequent request from one client is served by different servers then the application will not behave as it is supposed to be. 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 Processor or Server In-Memory. “Web.config” Changes:

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

Benefit of using this technique is that all the data in Session will be stored into altogether a different location or you can say a centralized location 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 need to take care of that all the objects which will be stored into session should be serializable. So if you are currently using In-Proc session state mode and intent that your application may require to have heavy sessions and you eventually need to shift it to SQLServer or the StateServer, then please take care of this “Serialization” issue from now, because once the application is running and is production environment, sometimes it 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 custom database, although we also configure it save session data in temporary database, but this database goes off when you restart your SQL Server.

It is very simple by using 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” specifies we need to add support for handling Session in SQLServer and “-sstype” specifies type of storage for Session State (If we need temporary database or a custom database), “c” represents 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 says to configure sessionState in “Web.Config” for allowing session data to be stored in Custom database and we need to specify the connection string for the same. You can also check the database which is 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 windows Service running on that server. “Web.config” Changes:

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

Benefit of using this technique is that all the data in Session will be stored into altogether a different location in this case a server which will be handled by windows service name “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 need to take care of that all the objects which will be stored into session should be serializable. So if you are currently using In-Proc session state mode and intent that your application may require to have heavy sessions and you eventually need to shift it to SQLServer or the StateServer, then please take care of this “Serialization” issue from now, because once the application is running and is 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 a 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 post is helpful. I welcome any comments; will try to improve in my next post if something is not good.