Estimate/Calculate Session Memory Usage

I would like to estimate the amount of memory used by each session on my server in my ASP.NET web application. A few key questions:

• How much memory is allocated just to have each Session instance?
• Is the memory usage of each variable equal to its given address space (e.g. 32 bits for an Int32)?
• What about variables with variable address space开发者_Python百科 (e.g. String, Array[]s)?
• What about custom object instances (e.g. MyCustomObject which holds various other things)?
• Is anything added for each variable (e.g. address of Int32 variable to tie it to the session instance) adding to overhead-per-variable?

Would appreciate some help in figuring out on how I can exactly predict how much memory each session will consume. Thank you!

The HttpSessionStateContainer class has ten local varaibles, so that is roughly 40 bytes, plus 8 bytes for the object overhead. It has a session id string and an items collection, so that is something like 50 more bytes when the items collection is empty. It has some more references, but I believe those are references to objects shared by all session objects. So, all in all that would make about 100 bytes per session object.

If you put a value type like Int32 in the items collection of a session, it has to be boxed. With the object overhead of 8 bytes it comes to 12 bytes, but due to limitations in the memory manager it can't allocate less than 16 bytes for the object. With the four bytes for the reference to the object, an Int32 needs 20 bytes.

If you put a reference type in the items collection, you only store the reference, so that is just four bytes. If it's a literal string, it's already created so it won't use any more memory. A created string will use (8 + 8 + 2 * Length) bytes.

An array of value types will use (Length * sizeof(type)) plus a few more bytes. An array of reference types will use (Length * 4) plus a few more bytes for the references, and each object is allocated separately.

A custom object uses roughly the sum of the size of it's members, plus some extra padding in some cases, plus the 8 bytes of object overhead. An object containing an Int32 and a Boolean (= 5 bytes) will be padded to 8 bytes, plus the 8 bytes overhead.

So, if you put a string with 20 characters and three integers in a session object, that will use about (100 + (8 + 8 + 20 *2) + 3 * (20)) = 216 bytes. (However, the session items collection will probably allocate a capacity of 16 items, so that's 64 bytes of which you are using 16, so the size would be 264 bytes.)

(All the sizes are on a 32 bit system. On a 64 bit system each reference is 8 bytes instead of 4 bytes.)

.NET Memory Profiler is your friend:

http://memprofiler.com/

You can download the trial version for free and run it. Although these things sometimes get complicated to install and run, I found it surprisingly simple to connect to a running web server and inspect all the objects it was holding in memory.

You can probably get some of these using Performance Counters and Custom Performance Counters. I never tested these with ASP.NET, but otherwise they'r quite nice to measure performances.

This old, old article from Microsoft containing performance tips for ASP (not ASP.NET) states that each session has an overhead of about 10 kilobytes. I have no idea if this is also applicable to ASP.NET, but it sure is a lot more than then 100 bytes overhead the Guffa mentions.

Planning a large scale application there are some other things you probably need to consider besides rough memory usage.

It depends on a Session State Provider you choose, and default in-process sessions are probably not the case at all.

In case of Out-Of-Process session storage (which may be the preferred for scalable applications) the picture will be completely different, and depends on how session objects are serialized and stored.

With SQL session storage, there will not be linear RAM consumption.

I would recommend integration testing with an out-of-process flavour of session state Provider from the very beginning for a large-scale application.