You are currently browsing the monthly archive for June 2007.
About a week ago, one of our early beta users pointed out that the single Seaside VM limit (plus a Maintenance VM) in the Web Edition is not practical. Since each http request coming into the Seaside VM acquires the transaction mutex for the duration of the request, a long running http request can effectively block all other requests.
An application developer cannot always predict how long certain requests will take. The developer needs to be able to count on concurrency in the framework, so that a long running request in one session won’t affect the response time for other requests.
We anticipated that users would eventually scale their systems to use multiple Seaside VMs and all along we felt that being able to scale an application by simply adding another VM or 2 to the server is a major advantage, however, we did not anticipate that multiple VMs would be required, which is why we set the 2 vm limit in the first place.
We haven’t made an official announcement (yet), but rest assured that when the Web Edition is released, it will not be limited to 2 VMs. I have to tip my hat to GemStone management. When they were presented with technical arguments against limiting the Web Edition to 2 VMs, they didn’t flinch. They get it that the Web Edition has to have enough punch for people to be successful using the free version.
Multi VM Web Architecture -Round Robin Requests
Most Seaside applications that are running in Squeak (or VW, or Dolphin) arrange for all http session requests to be routed to the same VM, using some flavor of session affinity. Given the GemStone limitation that only one concurrent request can be processed by a GemStone VM, if we were to use session affinity, we would have to allocate one GemStone VM per Seaside session – not acceptable.
Fortunately, with GemStone, Seaside session state (including continuations) can be persisted. With session state stored in the repository, any VM can service any http request and no session affinity is required. The load balancer need only round robin requests to an available VM. The session state for active users stays in the GemStone shared page cache (in shared memory), so each VM can quickly access the data if it is not already resident in it’s own memory space.
It’s relatively straight forward to set up such a load balancing scheme with Apache and FastCGI.
As for sizing considerations, the number of GemStone VMs required for a Seaside application should be based on the number of concurrent requests (not sessions) and the memory allocation for a GemStone VM should be based on the working set requirements for the largest request, not the requirements for the session (i.e., you can choose a session expiry based solely on your application requirements, rather than having to take memory impact of a long session expiry into account).
Given these considerations; the GemStone VMs will be smaller than their Squeak conterparts, but more GemStone VMs will be running in an installation.
I’ll be writing a post on the gory details of setting up Apache and GemStone.
Application Impacts – Concurrency Issues
As I have mentioned in an earlier post, when running with multiple VMs serving Seaside, you will need to worry about transaction conflicts.
[Updated: 3/17/2008] Please see series of posts (GLASS 101: Ready…, GLASS 101: …Aim…, GLASS 101: …Fire) for recent information on transaction conficts.
A transaction conflict occurs in GemStone when the same object is modifed by two separate VMs at the same time.
You will not have to worry about transaction conflicts caused by modifying your Seaside session state – we preserve the existing Seaside semantics that http requests for the same session are not processed concurrently.
In your current Seaside application, the places where a semaphore is used to protect access to ‘shared’ application data, are sites where transaction conflicts could occur in a multi-vm environment. In your assessment of your application you should also consider the places where you should be using a semaphore, but aren’t.
GemStone has a set of reduced conflict classes (RcCounter, RcIdentityBag, RcKeyValueDictionary, and RcQueue) that can be used to avoid transaction conflicts. We also have object locks that can be used to provide cross-VM access control. Both object locks (on WASession) and RcKeyValueDictionaries are used in the GemStone/Seaside port to avoid transaction conflicts in the Seaside framework data structures.
I’ll be writing a post with more details on transaction conflict avoidance, as well.
All in all, I am very happy to have gotten this kind of feedback early in the process. Our intent is to provide real value with the Web Edition and these changes are an important step in that direction.
Over the last week or so I’ve been heads down and hip deep in OmniBrowser.
With a little prodding from Avi Bryant and Lukas Renggli we have decided to base the tools for the Web Edition (pdf) on OmniBrowser. OmniBrowser is a meta-driven framework for building extensible Smalltalk tools. OmniBrowser is UI-neutral which is an advantage for GemStone/S since we have no native UI.
Using OmniBrowser we will define a set of tools that run within a GemStone/S server (sans UI). With the tool state and logic managed on the server the client tool UI can be very light-weight – doing little more than managing lists of strings, buttons and text windows. The overhead for maintaining multiple tool clients will be significantly reduced. Since the bulk of the heavy lifting is done by the server, most bugfixes/changes will be isolated to server code and not propogated to a multitude of clients.
In a client Smalltalk (VW, VA, or Squeak) we will build light-weight tool UIs that communicate to the server using GemStone/S GCI. Our first UI will be Squeak-based.
If we include an application server (like Seaside:) in the mix, it is easy to imagine the creation of web-based tools or even tools using windows-native or mac-native UIs. This could get very interesting.
The only real disadvantage to this approach is that we are spending more time getting the initial tool suite built, however, I think it will be worth the wait.
Last week I gave Chris Cunnington of Seaside Parasol a phone interview about GLASS. I met Chris at Smalltalk Solutions in Toronto and during the conference we shared more than a couple cold ones. He and William Hartford manned the Squeak booth and they did a bang up job.
Seaside Parasol provides Seaside hosting, demos and of course the Parasol newsletter. Chris tells me that the next issue should be out sometime in July, so check it out.
(gem)Stone Soup 