ASP.NET Session size limitation

Question

Is there some kind of Session size limitation or advisable value to not to surpass ?

In my web application I create a few DataTables to store user selections which a

Answer 1

You should always assume session is a very valuable storage and very limited. The consumption should be as little as possible, because you can never know how many users the application is going to support.

DataTable can be too large to store in sessions, unless it can be kept small enough.

Answer 2

I am assuming that you are having the session stored in "inProc" mode. In this mode, ASP.NET applications' session, cache etc are stored in the web server's RAM (via aspnet_wp.exe process). And .NET does not get to use all of it. There is a setting in machine.config which tells the threshold limit (by default 60%). Once this threshold is reached, IIS will recycle the worker process, and all the session information is lost.

Note that, if your server hosts more than one asp.net application, the 60% of memory is to be shared by all apps. So if the cumulative memory usage reaches the threshold the worker process still gets recycled.

Alternative to this, besides optimizing your application to use session sparingly,is to set the application to use session in out of process mode (using a stateserver or sqlserver to store session information).

Out of process mode can bring down your system performance.

Refer to this article for more information on Session State Management.

Answer 3

Here's a few notes about Session state:

• InProc (mode="InProc") session state is limited to the amount of memory available to the worker process. Only object references are stored, not the objects themselves.

Out of process state management serialises objects before persisting them:

• Out of Process state management using the session state server (mode="StateServer") is limited to the amount of memory available to the state service.

• Out of Process state management using SQL Server (mode="SQLServer") is bound only by the maximum size of the SQL image data type or the maximum permitted size of the database.

Obviously there still has to be enough memory available to the worker process to be able to pull an out of session object back into memory and re-hydrate for the duration of the http request.

As I mentioned previously, out of process state management serialises objects before persisting them.

This means that objects must be serialisable which excludes, for example, XmlDocument or anything that inherits from MarshalByRef.

Attempting to serialise objects of this sort will result in the following exception:

Unable to serialize the session state. In 'StateServer' and 'SQLServer' mode, ASP.NET will serialize the session state objects, and as a result non-serializable objects or MarshalByRef objects are not permitted. The same restriction applies if similar serialization is done by the custom session state store in 'Custom' mode.

Answer 4

Yes, it is reliable enough. It just isn't very scalable, so plan ahead. This will totally grind to a halt when you run it on more than 1 server.
And there is sort of a limit: Number-of-concurrent-Users * SizeOf-Session < Available-Mem

It depends of course on the size of the tables, storing a few kB is usually acceptable (although high traffic sites will try to keep it smaller).

If your users can share tables, then you can place that data in the Application object, a great saving.

And a session object is limited to the TimeOut setting, default is 20 min. One way to optimize memory consumption is reducing that, but that is a trade off with user convenience.