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

[Chris Muller]

> > 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
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..

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).

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!

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..

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..

Regards,
 Chris