- From: Mark Baker <distobj@acm.org>
- Date: Fri, 29 Oct 2004 15:12:51 -0400
- To: "Mullins, Chalon" <Chalon.Mullins@schwab.com>
- Cc: 'Savas Parastatidis' <Savas.Parastatidis@newcastle.ac.uk>, www-ws@w3.org, Ian Foster <foster@mcs.anl.gov>, Carl Kesselman <carl@ISI.EDU>, Steve Graham <sggraham@us.ibm.com>, Steve Tuecke <tuecke@mcs.anl.gov>
Hi, On Fri, Oct 29, 2004 at 11:15:32AM -0700, Mullins, Chalon wrote: > Mark, > > That's not transferring "all" state. I'm not sure what you mean by "all". What I'm talking about is transferring all data which is required in order to understand the semantics of the message; no shared context allowed. > Every solution I have seen mentioned > here deals with the issue of large amounts of state by storing it on the > back end, and passing information about how to get at it -- maybe a key, > maybe something else. I stick by my statement -- what gets in the way of > scalability is affinity to a particular endpoint. In my experience with scaling Web servers, what gets in the way is exactly the mechanism you describe there; "storing it on the back end, and passing information about how to get at it". By doing that, you prevent the server from freeing up resources as it needs, and end up requiring hacks like distributed garbage collection, and/or just throwing more and more server resources at the problem. > If I had to transfer all the balances and positions for my customers each > time so that I could value a portfolio, I would never be able to handle the > hundreds of thousands of concurrent users we do every day. I think you'd be surprised what you could handle. Most of the interesting work on scalable services over the past 10 years or so has been done with Web servers. There could very well be some scenarios for which that doesn't make sense, but in my experience stateless should always be your first choice unless there's a darned good reason not to use it. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Received on Friday, 29 October 2004 19:10:57 UTC