-----------------------------------------------------------
New Message on cochindotnet
-----------------------------------------------------------
From: SecCode
Message 5 in Discussion
Long Post.. Be prepared :-)
Some background and definitions to level-set
before we start on the State Service itself.
You typically employ the Out
Of Process state management options when you need to scale out your application
on a web farm. A web farm by its very definition is a group of servers that are
used to distribute the load across multiple nodes (servers). This can be
accomplished using hardware load balancers like Ciso LocalDirectors, F5 Big IP's
or others. It can also be done using the Network Load Balancing (NLB)
software that comes with the Enterprise version of Windows 2000 and Windows
2003. As load increases, it is simply a matter of adding more servers into
the load balanced pool to distribute the incoming requests.
The primary
reason that we need to save state in a separate location (rather than
inprocess/memory) is that, due to the stateless nature of the web, there is no
guarantee that a two browser requests will be served out by the same machine.
Ex. You could submit some form on the web that authorizes you by putting
something in session, but on the next request, you could be bounced to another
machine, that does not have that authorization session variable in its InMemory
store.
So what is needed is a storage mechanism that ALL
nodes/machines in the web farm can point to and share.
Session-State Storage
Mechanisms
<o:p> </o:p>
ASP.NET supports three separate
state storage mechanisms.<o:p></o:p>
<o:p> </o:p>
1. In
Process � Session state is
stored in-process to the ASP.NET worker process ( i.e in aspnet_wp.exe) which is
similar to what we have in classic ASP.<o:p></o:p>
<o:p> </o:p>
2. State
Server � Session state is stored
in an external �State Server� process on a remote machine or a single member of
a web farm.<o:p></o:p>
<o:p> </o:p>
3. SQL
Server � Session state is stored
in a SQL Server database (Can be on the web server or on a remote
machine)<o:p></o:p>
<o:p> </o:p>
The performance impact of each storage mechanism increase as
you move from the In Process to SQL Server with In-Process being the fastest and
SQL server being the slowest. As a
comparison, the design goal of the ASP.NET team was to provide at least 80-85%
of the performance for the SQL server option as compared to In-Process.
According to my conversation with Scott Guthrie (ASP.NET Architect and Group
Product Leader) internal perf testing has shown them hitting this goal.
There is only a couple of % points of diff between SQL
Server and State Storage so the choice between them should NOT be made based on
the performance criteria.
1.
<st1:place w:st="on"><st1:PlaceName
w:st="on">In-Process</st1:PlaceName> <st1:PlaceType
w:st="on">State</st1:PlaceType></st1:place> Storage
Option
<o:p> </o:p>
This is
similar to what we currently have in the Classic ASP model.
<o:p> </o:p>
Pros:
Default Option
Fastest performance
<o:p> </o:p>
<o:p> </o:p>
Cons:
Constrained to single machine. Restart IIS or reboot
machine and session state goes away.
Cannot share session across members of a web farm or a web
garden.
<o:p> </o:p>
<o:p> </o:p>
2.
State-Server
Storage Option<o:p></o:p>
<o:p> </o:p>
This is
a new option under ASP.NET. Session
state storage is in a dedicated �state server� process that can be enabled
either on a single machine in a web farm or a separate machine outside the web
farm dedicated to this process. The
�State Server� is actually a running instance of a Windows Service named
�Aspnet_state.exe�.
<o:p> </o:p>
Pros:
Ability to share sessions across a web
farm.
Session state can survive web farm reboots and IIS restarts
the machine that is hosting the state is not the one in
question.
<o:p> </o:p>
Cons:
Slower than in-process model as session data travels across
process or machine boundaries.
The state server machine is a single point of failure as it
cannot be clustered.
The state server machine cannot be taken out of service for
routine maintenance without affecting the entire web farm.
Need for a separate machine at additional cost outside the
web farm for true state support.
<o:p> </o:p>
<o:p> </o:p>
3.
<st1:place w:st="on"><st1:PlaceName w:st="on">SQL</st1:PlaceName> <st1:PlaceName
w:st="on">Server</st1:PlaceName> <st1:PlaceName
w:st="on">Session</st1:PlaceName> <st1:PlaceType
w:st="on">State</st1:PlaceType></st1:place><o:p></o:p>
<o:p> </o:p>
This is
a new option under ASP.NET. This
option offers the ultimate in scalability and reliability. It moves the
<st1:place w:st="on"><st1:PlaceName w:st="on">Session</st1:PlaceName>
<st1:PlaceType w:st="on">State</st1:PlaceType></st1:place> out of the ASP.NET
worker process into a SQL Server 2000 DB.
<o:p> </o:p>
Pros:
Web farm compatibility as all machines in a web farm can be
pointed to a single SQL server.
The SQL server can be clustered for reliability and
scalability so there is no single point of failure.
Preservation of state under both IIS restart and web server
reboot scenarios.
Taking a web farm out of service will not have any impact
on state.
<o:p> </o:p>
Cons:
Slowest
of the three options.
A
clustered SQL server as the State repository for true
reliability.
Recommendation
<o:p> </o:p>
Use SQL Server State
Management option if you have a choice.
<o:p> </o:p>
<o:p> </o:p>
To provide true reliability with the State Server option,
we would need to provide a dedicated server, outside the web farm, at each
load-balanced tier. And the state server would be a single point of failure as
Out of Process State Servers cannot be clustered.
In terms of pure performance, SQL Server is the slowest of
the three options. But in return for speed, we have a virtual guarantee that
<st1:place w:st="on"><st1:PlaceName w:st="on">Session</st1:PlaceName>
<st1:PlaceType w:st="on">State</st1:PlaceType></st1:place> will not be
lost.
Testing indicates
that the while the SQL server is still the slowest, it is off only by a few
percentage points as compared to the State Server option making it very viable
from the performance perspective as well.
Reliability is guaranteed, as you can host the SQL
Server database on a clustered SQL Server 2000 Platform. (Which I
believe answers your question about a fail safe session storage
mechanism)
NOTE to Admins:
Each machine's machine.config contains a machinekey element that assigns
values to two Crypto keys, validationKey and decryptionKey. Default is for each
machine to AutoGenerate these values which work fine when you are using a single
box. But when deploying on a web farm, each server MUST use identical keys,
otherwise a value encrypted/hashed on one server can't be unencrypted on the
others ( For e.g. You will get a message that Viewstate is corrupt ).
NOTE to DEVs:
<o:p> </o:p>
One item to be aware of when using either a State Server or SQL Server
for session state storage is that both require that the types stored in session
state be serializable.
Non-Serializable types work just fine in In-Process sessions, so this
issue will be encountered only when using either a State Server or SQL Server
for state storage.
<o:p> </o:p>
Serialization is the process of writing data that defines an object
instance to a storage mechanism for the purpose of recreating it at a later time
and/or place. ASP.NET must be able
to serialize objects stored in session state in order to store them to a State
Server or SQL server and be able to deserialize them to read them
back.
<o:p> </o:p>
Basically what this means for developers who are using this mechanism is
that, if they are creating custom data types which will be stored in SQL Server
or State Server, they MUST use the �Serializable� attribute, which will allow
ASP.NET to use the .NET Framework Binary Formatter to serialize and deserialize
the data type.
Regards,
- Anil
--------------------------------------------------------------
--
http://SecureCoder.com
-- Digital Security in
an Insecure
World
--------------------------------------------------------------
-----------------------------------------------------------
To stop getting this e-mail, or change how often it arrives, go to your E-mail
Settings.
http://groups.msn.com/cochindotnet/_emailsettings.msnw
Need help? If you've forgotten your password, please go to Passport Member Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help
For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact
If you do not want to receive future e-mail from this MSN group, or if you received
this message by mistake, please click the "Remove" link below. On the pre-addressed
e-mail message that opens, simply click "Send". Your e-mail address will be deleted
from this group's mailing list.
mailto:[EMAIL PROTECTED]
