CODEWITHSUNDEEP
asp.net-mvcsessioniis
Chase R Lewis
Chase R Lewis

Reputation: 2307

Handling MVC Session State on Multi-Server Production Environment

So started working for a company on my first production job as a developer where I am writing a MVC web application. Told for certain data we didn't want to have any persistent storage, so just keep it in session. I just finished setting up the production environment so that we can do automatic deployment to the servers.

I do so in a rolling deployment manner. Drain connections from a machine, take it down, deploy new code, bring it back up then do the next machine.

From my first test this seems to kill the session data, which was what I was worried about. Is there a way within IIS to transfer session data when a user switches machines, or do I need some sort of shared file storage to recover in the case the user has to be removed from a machine to load new code onto it.

I am using Big-Ip for my load balancer that does the draining and I don't think it necessarily knows anything about IIS. First experience with the complexities of production level deployment with no downtime requirements. I imagine, I'll need a file storage backup to 'recover' if necessary. Just want to make sure I'm not missing something.

Upvotes: 1

Views: 912

Answers (1)

Erik Funkenbusch
Erik Funkenbusch

Reputation: 93444

Best practice for a server farm (even if it's just two) is to NOT use session for anything. Apart from the fact that Session can cause performance problems (Session access is serialized and can slow performance as your load increases), Session is also considered transient storage, and can literally disappear at any time. When the IIS app pool is restarted, session is lost (either intentionally or unintentionally). Also, IIS can dump sessions even before they expire if it starts running low on resources.

Session is basically unpredictable, and unreliable. Anything you put in session should be rebuildable from your app if it finds the session data is gone.

Of course, this is for in-proc session. You can use a state server tied to a database, but this too will affect performance. Especially if you make heavy use of session.

In general, design your apps to NOT use session, unless it's for trivial things that can easily be recreated if they are no longer found.

Upvotes: 1

Related Questions