Which session state is best to use

[tshad]

I am running with Sql Server and am curious if I should use in-process,
State Server, or SQL Server.

By default, I assume I am using in-process (I could be wrong here, however).
I am not actually defining it in my web.config.

I was thinking about moving to Sql Server mode, but am not sure what I would
gain or lose by changing.

One thing I was curious about, was if this would make it easier to figure
out who was using our system at any particular time (their sessions haven't
timed out yet).

Thanks,

Tom

 

[Alvin Bruney [ASP.NET MVP]]

There is no right answer for this, rather there are recommendations based on
your requirements. If you move to sql server session, you incur a
performance penalty but you also get to use session in webfarms and gardens.
In proc is the default mode by the way, as defined in the web config file.

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________

 

[Brock Allen]

Two things:

1) I'd suggest not using Session state at all if you can avoid it. This isn't
always possible, but you avoid some types of problems later on if you can.

2) If you are going to use it, then don't accept the default of InProc. The
primary reason is that your worker process and/or AppDomain (essentially
the two different hosting environments) recycle very often (more than you'd
think) and as a side effect your in memory state (read: InProc Session State)
will be lost. It's odd, IMO, that this is even an option in ASP.NET. So,
in short: never use InProc Session State and configure it to be out of process.

 

[Alvin Bruney [ASP.NET MVP]]

It's odd, IMO, that this is even an option in ASP.NET. So, in short: never

use InProc Session State and configure it to be out of process.

It's not odd. Recycling application promotes greater stability and immunity
towards errant processes leaking memory among other things. There is a
reason why inProc is the default mode, because it works best for a large
number of applications. If you recommend switching modes, you should have a
sound reason and thoroughly understand the consequences such as performance
degradation occuring when session passes thru the
serialization/deserialization layer.

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________

 

[Brock Allen]

It's not odd. Recycling application promotes greater stability and

immunity towards errant processes leaking memory among other things.

Yes, of course. And that's why this is a welcome feature.

There is a reason why inProc is the default mode, because it works
best for a large number of applications. If you recommend switching
modes, you should have a sound reason and thoroughly understand the
consequences such as performance degradation occuring when session
passes thru the serialization/deserialization layer.

I think the vast majority people don't "thoroughly understand the consequences"
of leaving session state at InProc. The AppDomain/worker process recycle
a heck of a lot more than people realize and if your app relies upon session
state, then the robustness of keeping the data out of proc is the price to
be paid. As I said in my earlier post, I recommend avoiding session state
all together if possible.

But the reality is that most performance problems come from bad SQL and inefficient
trips to the database. Of course there is overhead to the StateServer Service
but if you're using InProc session state, then you'd only be making a cross
process call, as the StateServer Service would/should be configured on the
same machine. The overhead of the local access to the StateServer is dwarfed
by the network latency of hitting the DB.

As with anything, understand what you're doing. As far as performance, correctness
comes first. Don't optimize until you've profiled.