Trying to understand Magma performance

[Chris Muller]

Hi again,

On Tue, Nov 24, 2009 at 4:54 AM, Bart Gauquie <bart.gauquie at gmail.com> wrote:
> Dear all,
>
> I've been trying out the high availability options, and the performance of
> it still was rather bad. So I've been thinking that the reason is my (still)
> poor understanding about how magma works and how to use it.
>
> I further tried to interpret the performance of a single request.
>
> My demo application consists out of repositories: a todorepository & an
> userrepository which are basically a wrapper around an orderedcollection of
> todo's and users. Both form the variables of a Repositories object: this
> object is then saved as a root of a magma repository.
>
> My simple demo app renders an overview of all the todos & all the users.
> During this, session root todoRepository & session root userRepository each
> gets called 2 times, so 4 times; each taking around 170 mseconds to
> complete. 170*4 = 680 msecs of the 800 msecs of the request.
>
> First question is : why is Magma not caching if I for instance in the gui
> implementation:
> <snippet>
>   BMTTodoRoot>>renderTodosOn: html
>      html paragraph: 'Number Of Todos: ', self session todoRepository
> allItems size asString.
>      html unorderedList
>          list: (self session todoRepository allItems);
>          labels: [:item|item title].
> </snippet>
> call session root todoRepository two times right after each other? The
> behaviour of magma seems to be that it recreates the whole object
> todoRepository on each call.

No.  But calling the root does force a read to the server per the
current ReadStrategy.  When the buffers are returned to the session,
many may already be found to be present, those portions of the model
are not rebuilt in the session memory.

Often applications will set a ReadStrategy on start up and pre-cache
the portions of the model it knows it wants instant-access to (such as
shared control-data / flyweights).  Then, a different ReadStrategy is
used to select portions of the model to be worked by the end-user.

> If i cache userRepository and todoRepository in BMTRepositories then it
> flies; but as mentioned on the magma wiki, updates from other users/magma
> sessions are not seen then. Unless i do a commit on my own session, no
> communication is done with the server.

Ok, it sounds like you are doing all the things you need to do to find
out what works best for the particular requirements you must satisfy..

> If i cache the todorepository & userrepository and also call 'session
> refresh', updates from other magmasessions are seen and the local list gets
> updated; which is the behaviour I expect. Then the average response time
> becomes around 160 msec (instead of the previous 800). However while
> experimenting, I've noticed a possible issue with it: if in one magma
> session i clear all elements and commit that, the other magma sessions do
> not notice this (even with the refresh called on the session). Is this
> behaviour as expected ?

What do you mean by "clear all elements?"  I'm sure refresh should
have allowed other sessions to see the changes.  Note you may have
been in a "nested transaction", such as if you accidently called
#begin twice, then you would need to do two commits for other clients
to notice after their next #refresh..

> Is the idiom I'm using now: 'calling session refresh each time I want to do
> something with the repository' the correct idiom?

#refresh just updates the session state with the latest changes from
the repository.  It isn't absolutely required to "do something with
the repository".  In fact, if "doing something with the repository"
means a begin, commit or abort, a refresh is implied with those
operations.

> Is it safe to 'cache' the
> repository in a variable (each magmasession gets its own instance). Is this
> the way I'm supposed to use magma? Because using this, the performance is
> much better than the one I measured before.

You should cache those objects only if they truly need to be cached.
Often, for example, rather than caching such a large-grained
"Repository" object, a single-user may be only concerned with, for
example, one particular Account they are "working on" and so it may
only be necessary to cache that in their Session..

> I'm guessing that, in order to support much larger collections than 50
> elements,  I also should replace the simple OrderedCollection with a
> MagmaCollection, and do a paged read on them.

Size is one factor in the decision to use a MagmaCollection vs. a
Collection.  More important is how the collection will need to be
updated; MagmaCollections allow concurrent adds and removes, standard
Smalltalk Collections do not.  If a particular large (say, 10K
elements) Collection is mostly read-only, it can easily be cached and
often searched faster than a MagmaCollection.

So, the idioms are not too rigid, your design will instead depend on
the actual application requirements.

If you have further questions, please feel free to ask.

Kind Regards,
  Chris