Single User vs Multi User quetions

[Chris Muller]

Thanks for the excellent description Göran, you are right on.
Although, I am a little puzzled by a separate Magma server image that
would be faster than a locally-connected one.  That seems impossible,
due to the the serialization/materialization of the request/responses
work to do in the former.

I would also like to mention the next and final tier of scaling up
with Magma.  Yes, the new HA feature of r42 has a nice side-effect of
improving read-scale, but there is also a tool for improving read and
write AND memory scale; MagmaForwardingProxy.  The goal
ForwardingProxies are to create the illusion of a giant interconnected
"logical" repository, hosted by multiple physical servers.

The programming pattern is very simple, in the setter of an object
that links to an object in another repository, you simply send
#asMagmaForwardingProxy to set to a link rather than the actual
object.  For example, in a network-provisioning application, you may
wish to keep the UserAccounts in a separate repository from the
provisioned Connections.  Therefore, in
VirtualConnection>>#billingAccount: aUserAccount, you might have:

  billingAccount: aUserAccount
      billingAccount := aUserAccount asMagmaForwardingProxy

Each MagmaForwardingProxy knows its location, so when the
billToAccount is sent a message, the ConnectedSessions global is
searched to see if there is already a session open on that location,
otherwise one is allocated dynamically.  Therefore, this is also
useful for improve memory-scale to share "control" data objects that
don't change often, between many sessions (something you specifically
asked me about before, but I didn't have enough clarity about the
ForwardingProxies at the time to have mentioned it!).

I have always advocated using MagmaForwardingProxies as a way for
partitioning the domain by type, but in reality you can cut the model
any way you want.  For example, in our application we use the
last-digit of an Id to determine which repository it will go into,
which we hope will provide up to 10X improved read and write scale
over putting them all into a single repository.

 - Chris


On Fri, Feb 27, 2009 at 3:02 AM, Göran Krampe <goran at krampe.se> wrote:
> Hey!
>
> Milan Zimmermann wrote:
>>>>
>>>> It sounds like when I want to have more than 1 connection (session) to
>>>> Magma, I have to use the "Server/Client" connection mode described there
>>>> - the single user mode would not allow 2 correctly functional sessions,
>>>> is that correct?
>>>
>>> No, you may have many locally-connected sessions.  Which part of the
>>> documentation "sounds like" otherwise?
>>
>> Well, I misread. I realize "single user" is not equivalent to "single
>> session", this is what I misread:
>>
>> "Single-user mode
>> If you know will be operating in a single-user environment, starting a
>> second image to run the server may not always be convenient."
>>
>> I inferred that multi user requires client/server environment, (which can
>> run in single or multiple images - I hope I understand correctly that this
>> is true), but I erroneously assumed        "single user" = "single session."
>
> I am not entirely sure you got it. :) If I rewrite what you wrote it seems
> you say "a client/server environment running in a single image"? That sounds
> like a contradiction, depending on what you mean with "client/server" of
> course.
>
> Let me try to explain this as I understand it :)
>
> Magma can always have multiple sessions and one session typically
> corresponds to one user (or other process that works with the db). In
> Gjallar we have one session per logged in user + one session per frequently
> running background service.
>
> One way to run Gjallar is using a single image - this is the "local"
> configuration. All sessions (MagmaSession instances) live in the same image
> and communicate with the "server parts" (MagmaRepositoryController etc) in
> the same image that in turn write to disk.
>
> Each session creates its own "copy" of the domain objects that are loaded
> from the db, since it needs to be transactionally consistent for that
> session (regardless of other sessions doing txns).
>
> This is a very nice way to use Magma when developing and this is how Gjallar
> has been developed (and even deployed!) most of the time.
>
> The next step is to separate the "server parts" of Magma into its own image.
> The obvious reason to do this is in order to have multiple images running
> with say 5-10 MagmaSessions in each. This is a classic way of scaling a
> webapp. Use say 5 images with 5-10 users per each (use a load balancer in
> front, like say Apache) - have each of these 5 images connect to a single
> Magma server image that in turn writes to disk.
>
> One funny thing is that splitting out the Magma server into its own image
> actually seems to improve performance even when using just a single "client"
> image! So the network communication is obviously not a big deal.
>
> The latest High Availability stuff in Magma means that you can take this
> another step and create "slave servers" that continuously mirror the master
> server and are readonly and can thus offload read operations from the single
> master server image. Definitely nice and should help scaling.
>
> regards, Göran
>
> _______________________________________________
> Magma mailing list
> Magma at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/magma
>