Different ways of storing data in session state

Question

I have been asked up to come up with a state management strategy for a ASP .NET / MVC C# 3.5 web app

I have chose to go with storing sessions on a state server - this will be a separate physical box. I am concerned about the time that would be taken to serialize/deserialize objects when storing into sessions...

Does anyone know of a technique to get maximum performance when doing this?

Also would something like compressing information before storing it in session help or would this also result in slower performance times.

EDIT: I am using a separate box for the state server as we will have multiple web servers.

Answer 1

Personally the most common elements here are to work with reducing the amount of information put into session.

Compression MIGHT save space, but it is going to take more CPU time to get it done, more than likely causing either reduced performance or at minimum no net gain. Unless you are talking about REALLY big objects.

Answer 2

Example of Zip Compression on Session, Application, and Cache, used right here at StackOverflow.

Answer 3

Make sure you disable Session State on pages that don't use it. "By default, the ASP.NET session state manager performs two accesses—one read access and one write access—to the session data store in every request, regardless of whether the page requested uses session state." --MSDN Magazine

Answer 4

Be careful you're not trying to prematurely optimize your solution. Before implementing something like Session compression, it would probably be a good idea to conduct a series of benchmarks to determine if something like that is even necessary in your application.

Answer 5

You sure you'll be storing that much data in your session storage? Typical use of a session for a single user is a few hundred bytes!

As for serializing and de serializing, with that kinda small size is negilable.

Of course you'll be expecting more users than that, but still.

If your storing large amounts data in your session, then IMO, your doing it wrong.

Answer 6

Several have pointed out that too much data in session state per-user is a sign of a problem, but they haven't directly pointed at the solution to it: keep a user SQL database and store all the user info in that. Then the session state typically consists of just the logged in user's id. Any other state is probably directly related to the user's current activity, which suggests it can possibly be carried along more appropriately as in-memory cookies or querystring variables. Often this is the better option anyway, so that things to get into a corrupt state when users click their Back and Forward buttons.