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:
- In-Proc
- SQLServer
- 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
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.
No comments:
Post a Comment