SQLServer session state performance issues

[John Q. Smith]

I'm trying to find out some of the details behind OOP
state management with SQL Server. For instance
- how long does the session object live on any server? Is
it created and destoyed with each page request?
- will each reading of a session variable cause a round
trip to the DB server? or does the complete session live
within the HttpContext object?
- when asp.net session state is enabled (in any mode),
after a session has been created, will it always be called
up into the HttpContext object with every page request,
even when no reads or writes to session variables occur?
- I've read that both OOP options must
serialize/deserialize the session data, so is the only
performance difference between stateServer and SQLServer
the overhead involved with accessing/reading/locking the
DB?

thanks for any info provided
- John

 

[Hermit Dave]

okay will try and answer some of the questions...
1. Any data saved into session object is by default bound to what you
specify in you web.config file...
if you dont specify any values... it will take the default values from
machine.config file.
if your application's web.config has session to 30 mins and your
machine.config has a setting of 10 mins...
the objects in session will be kept alive till 30 mins from last request
handled by aspnet worker process

2. if you are using sql server to maintain session state.. any read write
would cause a round trip to the db.

3. The way i think its relation with HttpContext is by the session id cookie
passed by the browser or from the header if you are using cookie-less
session
4. Yes you need to serialize / deserialize data if you need to write to
State server / SQL server based session state storage.
And the only difference is you can have State Server as a local process
on one of the web boxes or you can specify a dedicated server
And with SQL Server... the round trips to read and write any data...

 

[bruce barker]

session state is maintained by a httpmodule. All HttpModules used for a page
request are created and destroyed on each page request. HttpModules
implement two methods: Init & Dispose

the default sql session handler is very simple. on each page request, a new
Session object is created,

Init- this is when the session data is read from the sqlserver and
serialized back into objects
Dispose - this is when it serializes the data out to the sqlserver.

with sqlserver session state, the objectes are serialized to to a table,
and deleted by a stored proc that is run on a schedule.

the stateServer works as above, but rather than storing the xml in a table,
its stored in a hashtable on the shared server.

the inproc session manager stores a reference to the actual object in a
static hash table and thus requires no serialization. it runs a timer to
know when to free up session objects, and fire on session end event, when
this happens.


-- bruce (sqlwork.com)

 

[Hermit Dave]

you might want to have a look at this one

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/aspnetsessionstate.asp

 

[Guest]

Thanks to both of you for your feedback. That is a very helpful link Dave. To summarize the answers to my questions:
1. The session state is part of HttpContext. Once a session exists, the session data is retrieved from the state provider with every page request. The data is loaded into local memory and exists only as long as it takes to process the request. This means that session data is not cached on local web servers, it is retrieved fresh from the remote provider every time.
2. There are 2 round trips to the DB with every page request: a read (update) and a write. While a page is processing you can access one, some, all, or none of the session variables without affecting the hits on the DB server. Session variable reads and writes are done in local memory.
3. Yes, the entire session data set is loaded into the HttpContext object whether the page uses those data or not.
4. As far as I can tell, the only performance difference (between the two OOP options) is the overhead involved with SQL Server itself - establishing a connection, reading and writing (via stored procs).

John