Clever Geek Handbook

Different ways to store data in session state

I was asked to develop a staffing strategy for ASP.NET/MVC C # 3.5 web application

I decided to go with saving sessions on the state server - it will be a separate physical box. I'm worried about the time it will take to serialize / deserialize objects when stored in sessions ...

Does anyone know a technique to get the best performance while doing this?

Also would it be like compressing the information before storing it in the session help or it would also result in slower running times.

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

0


source to share


6 answers


An example of Session, Application, and Cache Zip Compression as used here on StackOverflow.



+1


source


Personally, the most common elements here are working with reducing the amount of information placed in a session.



Compression MAY save space, but it will take more CPU time to complete, which is likely to result in decreased performance or at least a net gain. Unless you are talking about REALLY large objects.

+2


source


Make sure you turn off session state on pages that don't use it. "By default, the ASP.NET Session State Manager performs two accesses, one read and one write access to the session data store on every request, regardless of whether the requested page is using session state." - MSDN Journal

0


source


Be careful, you are not trying to optimize your solution prematurely. Before implementing something like session compression, it would probably be a good idea to run a series of tests to determine if something like this is required in your application.

0


source


Are you sure you will be storing that much data in session storage? A typical session usage for a single user is several hundred bytes!

With regard to serialization and serialization, this small size is inflexible.

Sure, you expect more users, but still.

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

0


source


Several of them pointed out that too much data in the session state for each user is a symptom of a problem, but they did not point directly to its solution: save the user's SQL database and store all user information in that. Then the session state usually consists of only logged in user ID. Any other state is likely directly related to the current activity of the user, which suggests that it could be carried in a more appropriate way in the form of cookies or request variables. This is often the best option, so everything to get into a corrupted state when users press the Back and Forward buttons.

0


source






More articles:


All Articles