0

We were using default session state (in proc) in our application which we've built on top of Orchard. Now management has decided to install a load balancer in between. To make our sessions still work, I thought to go with Out of process session state. However, I am a bit confused that whether should I enable it in the 'Orchard.web' module of in specific modules where I've used sessions.

I was trying to search out if Orchard supports out proc sessions some other way or it should be the similar way like a normal asp.net application would have.

Any help would be appreciated

Peeyush
  • 95
  • 8

2 Answers2

1

First off - I'm pretty certain that the Orchard team recommends avoiding session state at all costs. Anything that has session state is (by definition) stateful and that makes scaling outwards harder. However, assuming that you cannot avoid it:

1) It's just an ASP.NET application, the normal rules apply. Ensure the same machine key is set in app config, configure the session state mechanism of your choice (SQL/state server) and configure the appropriate values in web.config.

however

2) The standard ASP.NET session state implementation has really poor locking. This can lead to bad responsiveness issues for your pages. Check out this excellent question (and linked posts) on session state performance. You should evaluated for yourself whether you have any need for locked session state. We had to remove session state entirely in order to provide acceptable performance for our applications (and we've never looked back or found a reasonable argument for session over caching since

Community
  • 1
  • 1
Paul Devenney
  • 889
  • 6
  • 18
  • Couldn't agree more. Session usage is generally considered a bad practice (it comes with a huge price). Http protocol is stateless by design so any attempt to maintain a server-side *session* is a workaround. The default session implementation is pretty poor indeed (forces synchronous request processing) - there are better ways to achieve similar behavior (caching et al). – Piotr Szmyd May 28 '15 at 23:04
  • Well, technically, we *are* using session in quite a few places, when we use `TempData`. It's less problematic than general-purpose session state though, because it's very volatile, and with some properly configured affinity, it works fine. – Bertrand Le Roy May 30 '15 at 00:24
  • Furthermore you can use different TempData providers that won't use sessions, but e.g. cookies: https://github.com/brockallen/CookieTempData – Piedone Jul 02 '15 at 23:24
1

The classic solution to scaling is to use sticky sessions. Most of the load balancers have this setting and this will allow you to keep using the inproc session. And if you don't plan on auto scaling, so you will always have a fixed number of servers behind your LB then it is a solution that you should carefully consider.
Going out of proc can give you some headaches, like marking all your classes that you put in session as Serializable.

Liviu Costea
  • 3,624
  • 14
  • 17
  • ...and if a single server goes down, all the users on that server lose their session. So you need to bear that in mind. The ideal is to avoid sessions entirely as it is by far the most scalable solution when you have a stateless server. – Paul Devenney Jun 05 '15 at 18:10