Continuation Farms
Bill Clementson got an email wondering how continuation-based session state works in a server farm. This objection comes up a lot, but I've never been able to see it as a very big deal. Yes, session affinity - making sure the same user always gets redirected to the same server - is an absolute must, but that's true for most kinds of session state. So the only real problem is what to do when a server goes down. Frankly, I bet that for 99% of the applications out there, having one session in every 10,000 have to be restarted because of a server crash is going to cause so little grumbling as to be unnoticeable - and one in 10,000 would be a pretty unreliable server. The other 1% have to explicitly checkpoint onto shared storage at critical points. In languages where you can't easily marshal the dynamic state of a program, this might be a pain, but in Smalltalk it amounts to one line of code - just ask the VM to save the image.
But maybe I'm not taking this problem seriously enough. Is there some world of highly unreliable servers and extremely valuable session state (as opposed to domain state which is presumably kept in a database anyway) that I'm oblivious to?
Comments
Continuation Farms
[Alex Peake] September 1, 2003 11:45:28.694
The Session Affinity issue is just a matter of Scalability. If you use Session Affinity, then you break the basic (statistical) rules that assure large scale scalability of ("scale-out") Web Farms. If Scalability is not an issue, which for most non-commercialand many commercial web sites will be true, then you can use Session Affinity and indeed continuation based web servers are a wonderful breakthrough. I, like many others, must rely on the likes of Microsoft to give us the performance numbers on scalability in various configurations.
Affinity
[Gordon Weakliem] September 1, 2003 16:25:26.707
ASP.NET applications have a similar issue if you're using ViewState. ViewState is basically an encrypted version of the values of the controls on the page (including things like all the items in a select control, or the selected item; you can also add arbitrary key/value pairs to the ViewState). In a clustered app, you just have to ensure that every server is using the same key to encrypt/decrypt the viewstate. Now with continuations, I suppose you have to worry about the execution state of the entire application, but I wonder you couldn't serialize enough application state into the request to handle that.
Scaling Up
[Avi Bryant] September 1, 2003 19:49:42.088
Alex, I don't see how session affinity breaks the statistics of scalability at all. All you're doing is changing the granularity by which the load can be distributed. We could talk about "request affinity", where all of the packets for a single request have to go to the same server, or even "packet affinity", where all of the bits for a single packet do, but we already take these as givens. They don't mess up load balancing, because there are so many bits/packages/requests that it all evens out in the end. Session affinity is no different, just coarser - which means you need higher total traffic to even things out, but if your traffic's not very high, you don't have a problem in the first place...
The one theoretical case I can see where session affinity would indeed be a scaling problem (as opposed to a failover problem) is if you had a situation with a very high number of requests but a very low number of sessions. This isn't going to happen when a session corresponds to a human posting requests from a web browser, however: you shouldn't need load balancing to handle the speed at which a single user can click links.
Scaling Up
[Alex Peake] September 1, 2003 23:19:26.099
At this point, I must defer to the "experts" (if only I could figure who they were ;)). "Down in the trenches" we mostly have to select by what we are informed by "the community", which in this case includes Microsoft's recommendations of how to build scalable systems. I do not have the resources, nor probably the skill, to compare the continuation based (machine affinity) approach under load vs. the "do not use machine affinity" approach recommended by Microsoft. They, perhaps because of the products they have to offer, recommend using an RDBMS (in most cases) to store state across, and between, sessions.