hi-traffic websites & session-state

[John A Grandy]

for high traffic public websites , what are the proven options for
session-state storage & management ?

is an out-of-process state-server generally preferred over a sql-server ?
what are the relevant criteria ? is the primary criteria max expected total
storage size (for all active sessions) versus max ram available on the
state-server machine ?

if ADO.NET objects (such as small DataTables) must be stored in
session-state , is any custom coding required for them to be serializable
(as is required for out-of-process session-state) ?

are custom session-state management solutions common ? ( where the exact
session-state data loaded & saved is dependent on the context of the page
request )

 

[Kevin Spencer]

is an out-of-process state-server generally preferred over a sql-server ?

what are the relevant criteria ? is the primary criteria max expected total
storage size (for all active sessions) versus max ram available on the
state-server machine ?

Out-of-process state-server and SQL Server are generally used in WebFarm
scenarios.

if ADO.NET objects (such as small DataTables) must be stored in
session-state , is any custom coding required for them to be serializable
(as is required for out-of-process session-state) ?

You only need serialization when using SQL Server for Session State.
In-memory Sessions don't require serialization. As for the serializability
of various classes, refer to the CLR reference in the .Net SDK. All classes
CAN be serialized. However, some of them can be implicitly serialized (such
as strings, numbers, and yes, even DataTables) , and most can not.

are custom session-state management solutions common ? ( where the exact
session-state data loaded & saved is dependent on the context of the page
request )

Not sure. However, the "common-ness" of the use of a particular
configuration is not as important as the situation you are developing
against. Make your decision based upon that criteria.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[Joe Fallon]

There are 3 options for storing Session state.
InProc does not require serialization.

But the other two do require objects to be serializable.
So if you use a stateServer (RAM on another machine which all Web Servers in
the farm point to) then you must have serializable objects.

Depending on your load SQL Server may actually be faster than a stateServer
that uses RAM.
SQL Server caching plays a part in that counter intuitive statement.
SQL Server is also more reliable and scalable than a stateServer using RAM.
(But more expensive too.)
If cost is no object go with SQL Server.

If you need to support multiple back end databases then use a stateServer.
(since you can' t use Oracle or DB2 yet.)
I think ASP.Net 2.0 fixes this issue and allows any back end DB to be used
for storing Session state.