| |
NCache Session State Management
An ASP.NET State is used to keep
data across a sequence of user
requests to the server. This
Session State is usually
maintained from the first user
request until a specific period
after the user’s last request,
usually around 20 minutes.
If your application is running
on only one server, you can use
the standard ASP.NET Session
State without any problems.
However, if you want your
application to run in a
server-cluster/server-farm, then
you need to make sure that
either the Session State is
available from all the servers
in the farm or you use “sticky
sessions” feature of your
load-balancer.
The problem with sticky sessions
is that they limit your
application scalability because
the load balancer is unable to
truly balance the load each time
it receives request from a
client. With sticky sessions,
the load balancer is forced to
send all the requests to their
original server where the
session state was created even
though that server might be
heavily loaded and there might
be another less-loaded server
available to take on this
request.
ASP.NET provides a mechanism for
you to share Session State
throughout the cluster. But, it
has its own scalability
problems. ASP.NET allows you to
either point all your servers in
the server-farm to one
particular server for Session
State or point them all to a SQL
Server. Both of these approaches
force you into a
single-point-of-failure scenario
and they’re also not very
scalable because all the load of
accessing the Session State is
shifted to one server.
The answer to all of this is to
have Session State truly
clustered. This way, it does not
matter on which server the
session was actually created
because the session lives in the
entire cluster. The user request
can then be forwarded by the
load-balancer to the most
appropriate server. This
approach is also highly scalable
and there is no single point of
failure.
NCache Clustered Session
State
NCache provides support for
clustered Session State in .NET.
Since NCache is a clustered
object cache, it already has all
the capabilities of clustering,
synchronization, and
concurrency. And, NCache
Clustered Session is simply a
client of NCache that leverages
the clustering built into
NCache.
As a result, you get a high
performance in-memory clustered
Session State object with
NCache. This clustered Session
State object provides extremely
fast performance and
automatically supports different
clustering topologies
(Replicated, Partitioned, and
Client Cache).
NCache Session State object
provides the same interface as
the standard ASP.NET Session
State object. This means that
your code change is very
minimal, limited only to
changing the names of the
namespaces you have to use.
Much Better Than ASP.NET
Session State
If you’re using ASP.NET Session
State in a server-farm
configuration, you’re most
likely using one of the
following approaches:
-
Sticky Sessions:
The problem with this
approach is that it prevents
the load balancer from truly
balancing the load. All the
requests are sent to their
original server regardless
of how much load is on that
server. And, since not all
sessions are of same length,
this can easily overload one
server and kill the
performance of the entire
application, even though
there may be many server
sitting almost idle.
-
Out-Of-Process Mode Session
State Shared by All Servers:
In this approach, you
define “Out Proc” Session
State on one server and then
have all servers in the
server-farm point to it.
This has extreme scalability
and availability issues.
You’re not able to scale up
by adding more servers to
the farm because one server
is becoming the bottleneck,
thereby defeating the entire
purpose of server-farms.
And, you’ve put yourself in
an single-point-of-failure
situation where one server
going down would bring down
the entire farm’s sessions.
-
SQL Server Mode:
In this approach, you keep
all the session data in SQL
Server. This approach has a
great performance problem
because not only are you
accessing data from a remote
server’s hard disk, you’re
also competing with all your
other database transactions.
And, again, you’re not
really able to scale up your
application by adding more
servers to the server-farm
because of your dependency
on a single database server.
As compared to the above
options, if you use NCache
Session Management, you’ll be
able to achieve all the goals of
using sessions and web-farms.
They are:
-
Scalability:
Because NCache Session State
Management uses the
underlying NCache Clustered
Cache, you’re able to scale
up by adding more servers to
the server-farm. NCache
Clustered Cache provides a
rich set of clustering
topologies to meet your
needs and grows almost
linearly with your
server-farm size.
-
Availability:
Since NCache ensures that
there is no single point of
failure in clustered cache,
you’ll have high
availability for your
session data. Even if any
one server goes down, you’ll
be able to fetch data from
other servers without any
problems.
-
Performance:
One of the reasons for using
Session State is to cache
some data that is specific
to a particular user but is
needed over and over again
during the user’s session.
And, since NCache Session
Management is a high
performance caching
solution, you’ll be able to
improve your application’s
performance greatly with it.
|
|
