Scaling Seaside apps (was: [Seaside] About SToR)

[goran at krampe.se]

Hi!

Chris Muller <chris at funkyobjects.org> wrote:
> > > What made you decide to use a session pool rather than have a magma
> > 
> > > session per Seaside session?  Is any of the stuff you've built to
> > marry 
> > 
> > Currently we have a compromise - we use one magma session per Seaside
> > session, but it is allocated from a pool. This means we cut out the
> > session creation time, but more importantly - the session is "hot" so
> > we
> > keep the cached objects of the session.
> > 
> > But the problem with using one Magma session per Seaside session
> > (which
> > thus remains for us) is that if you have a large persistent domain
> > model
> > AND you wish to cache quite a bit of it - then you get:
> > 
> > 	numberOfObjectsInRAM = numberOfSeasideSessions *
> > objectsCachedPerSession
> > 
> > So if you have 100 concurrent sessions and 10000 objects cached per
> > session you get a million objects. Ouch.
> 
> This is just a physical memory ouch, right?  An internal structure of

Yes.

> only 10000 objects cached per session will keep each session from
> getting bogged down with a huge dictionary cache, not to mention more
> supportive of concurrent processing.  I really think a caching
> 100-thousand objects in one shared session would hurt worse..

Ok. But again, 10000 was just a number out of thin air. Perhaps I want
100000 - I don't know. But I do know that we will need to be able to
support about 100 concurrent users approx.

> Let us clarify that this is a general web programming ouch or, more
> generically, a "three-tier" ouch rather than anything specific to using
> Magma.  No matter what DB is used, you have to choose to share the
> model between sessions or each session works on its own copy of the
> model (or some hybrid of the two).

Well, I presume you could *in theory* have some kind of copy-on-write
mechanism thus sharing non-modified objects and still maintaining the
principle of different sessions maintaining their own logical view.
Doesn't GemStone use shadow pages in some kind of copy-on-write scheme
for example? Not sure, my memory may be wrong.  

> Sharing the model requires the need for thread-safety throughout, not
> to mention throwing out commit-conflict detection (that one clients
> changes affect the db transactions of other clients) and consistent db
> views..  Scary!

Well, the idea was to *not* perform modifications in the shared Magma
session. They would be performed in separate allocated sessions. And
AFAIK thread safety is not an issue in a readonly model. And the same
goes for conflict detection etc - still should work fine.

But this approach was more like a mind experiment in how we could make
the RAM requirement say 50 times lower. :)

> Has anyone tried the suggested approach to scaling with Magma; using
> multiple images, CPUs, servers?  This permits the simple 1:1
> application architecture, is ultimately more scalable and, probably
> more economical in the end, because cost of h/w < cost of complicated
> s/w architectures..

Well, we probably will have to. But we are not there yet. ;)
 
> Programming to the simple, one session per web session, permits your
> app to scale by simply adding more hardware with absolutely _no
> changes_ to the code.
> 
> In fact, the only thing you have to do is go into each Seaside
> configuration panel and point the "Magma DB location" to the remotely
> hosted database rather than a locally-hosted one.  This has been
> demonstrated via the "Magma Seaside" demo available..).
> 
> And you don't necessarily need additional hardware to at least *try*
> this approach, in fact, just multiple images on the same machine would
> prove its viability and leverage any multi-core abilities of that
> machine in the process.  I hope you will at least try it out and report
> back how it went..

Sure, we don't intend to make any experiments in session management at
this point. I was just "airing a concern" I have. :) We will see.

Btw, the approach of wrapping each request in an commit block (or as we
do - just an abort before performing the request (we run modifications
to the model in separately started transactions)) has a noticable "feel"
penalty. 

Seaside typically does a redirect so each "click" will result in two
http requests - each doing an abort. And even if nothing at all has
changed in Magma (and we are still running Magma in the same image even,
so there is no roundtrip involved) it gives a sluggish feeling. Doing a
cheap trick (which will not work if we go multi-image) by using a
transaction counter in the image we can avoid making the aborts if we
know that there have been no transactions since last abort. This
improved the "feel" a LOT.

I did profile the aborts trying to figure out why they take so long even
when there are no changes - but can't recall right now what it was. 

regards, Göran