Out of proc SessionState memory management

5
votes

We're using an out-of-proc session state service/ASP.Net Session state. We know were having problems with this as it's been abused in the past, too much stored in session state too often, so were in the process of moving onto a more scalable system.

In the meantime, though, we're trying to get our heads around how a session state service manages it's memory and what limits do we have. But none of the Microsoft docs seem to go into any details.

Specifically I want to know:

  • What are the limits to how much "the standard" out of proc session state service (installed along with IIS in the windows management console) can store? (x64)
  • Is there a per user limit?

by standard service, I mean this one:

enter image description here

1
c#asp.net.netsessionasp.net-session
possible duplicate of ASP.NET Session size limitation – Erik Philips
I've seen that already, but that question isn't very specific, it's unclear whether he's talking about inproc of outpfproc or x32/x64. TBH I don't understand how that question got 5 upvotes. Secondly that answer doesn't answer the question (at all). – Liam
As I read it, Out of Process state management using the session state server (mode="StateServer") is limited to the amount of memory available to the state service. so that would answer your first question, and implicitly answers the second for a user with limited to the amount of memory available to the state service.. So it's just a limitation on either a 32bit machine (2gb) or memory installed as 64bit is roughly 128gb to 16tb depending on the OS. – Erik Philips
@Liam Does the answer to your first question depend on how much memory is available to the StateServer? I see this referenced more commonly as StateServer than out-of-proc or "State Service" – AnotherDeveloper

1 Answers

1
votes

There is no limit beyond that of the machine hosting the service. If it has 16 gigs of RAM, assuming a few gigs are used for other processes / the OS / etc., there would be something like 13 GB of memory available for the session data. The data is not persisted to disk so the data only ever exists in RAM / memory; this is why when you restart the service all sessions are gone. The memory is volatile and works like a RAM disk.

If you're reaching the memory limits of the machine hosting your session state service, you are either storing too much data per user, or have too many users storing a little data. You're already on the right track as the next step is moving to a distributed session state provider to scale correctly. This is often achieved via a distributed caching system which comes with a session state provider, or by writing your own provider against said system.

There is no per-user limit on data, but note that out of process communication always happens via serialization. Therefore, there is a practical limit as serializing/deserializing a gig of user data per request is going to be very slow no matter how you approach it.