Redis instead of Session in ASP.NET Webform

[AliKolahdoozan]

Good day everyone,

We have an old app(ASP.NET Webform) which creates more than 200 Session after login(I have not developed this so please do not think I am an idiot). After going to some pages, the number of sessions would be 400. I tried to keep to sessions inside the DB, but nothing has changed. So then I created my own cache inside the DB and did close the session state inside the whole app. Now everything plays with the DB instead of sessions in the memory. I did put some important ones in the httpcontext cache also.

I need to know what can I do with Redis to improve the performance. If I use Redis, then the app should go and get its data from Redis cache instead of my DB and it would be the same. Each call would be a pain again. May I know what is the solution?. If something like Redis means session lock and etc , what is point ?. The second issue is serializing the values. Should I do that for Redis also?.

 

[admin]

Hi Ali,

ScaleOut Software does not provide a Redis product, so I'm afraid we can't help you with specifics about Redis. ScaleOut does provide its own in-memory session provider product called ScaleOut SessionServer, though, which I encourage you to evaluate.
And these are great questions, so no, we definitely don't think you're an idiot--you've identified a number of known weaknesses in the old ASP.NET session model.

Anyway, the point of moving to an out-of-process provider like ScaleOut (or, to a lesser extent, Redis) is that you gain reliability and scalability in your storage of session data while at the same time minimizing the out-of-process perf hit as much as possible. In contrast, SQL Server has a number of limitations for this kind of workload, such as:

• Unless you have a really expensive SQL Server cluster, you're limited to a single SQL host (no failover, no scalability).
• You're being slowed down by disk IO.
• You're bogging down your expensive database server with a lot of additional session state chatter.

Regarding your specific concerns:

Locking: Yes, ASP.NET's pessimistic locking scheme is tough to work around if you expect concurrent accesses from the same user/session. The only tool MS gives you is the @ Page directive's EnableSessionState attribute--set it to false or ReadOnly on as many pages as possible to reduce lock contention. See https://msdn.microsoft.com/en-us/library/ydy4x04a(v=vs.100).aspx

Serialization: Yes, objects stored in session state are serialized prior to being sent to any out-of-process session provider. This is another good reason to keep your session data small. ScaleOut's session provider does some aggressive in-process caching to minimize serialization overhead, but we can't totally eliminate it, so it's still important to keep your classes lean.

So you're smart to start moving important elements out of session state and into a storage medium with more flexible API. This a best practice for ASP.NET in general and we advise our customers to do the same (many use our generalized caching APIs such as the NamedCache library or the newer ScaleOut.Client API). Large session dictionaries are problematic for a number of reasons (serialization overhead, network overhead, etc...) and should be avoided.

We have a number of other general performance suggestions listed in this post that you'll find helpful. When you combine these practices with a product like ScaleOut that's optimized for this kind of workload then you can get very good performance from session state, so long as it's used judiciously.