Trying to understand Magma performance

Tue Nov 24 10:54:09 UTC 2009

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.

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.

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 ?

Is the idiom I'm using now: 'calling session refresh each time I want to do
something with the repository' the correct idiom? 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.

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.

Thanks for any advice,

Kind regards,

Bart

On Fri, Nov 20, 2009 at 9:07 AM, Bart Gauquie <bart.gauquie at gmail.com>wrote:

> Hi Chris,
>
> You are correct that 340 msecs is fast enough a reply of a web page. I was
> reasoning that if a single user already takes 340 msec, a medium load would
> be a lot slower.
>
> I'd actually rather have scalability over raw speed. The systems I've been
> using so far have high raw speed, and no scalability: it just gets slower
> and slower under load.
>
> I will do a test if it scales enough for my requirements, and experiment
> with the high availability options.
>
> Kind regards,
>
> Bart
>
> On Thu, Nov 19, 2009 at 7:24 PM, Chris Muller <asqueaker at gmail.com> wrote:
>
>> Hi Bart,
>>
>> > To my opinion, 340 msecs not at all that great a performance.
>>
>> One-third of one second is fast enough web page response isn't it?
>> I'm patient enough to accept pauses up to one entire second as long as
>> the software is doing a lot of work for me.  Many, many web pages out
>> on the net don't respond within 340 msecs.
>>
>> Which makes me wonder whether your concern is actually about scale.
>> Magma is stronger in scalability than in raw speed.  The benchmark you
>> referred to is an indicator of Magma's speed, not its scalability.
>>
>> Regards,
>>   Chris
>>
>>
>>
>> On Tue, Nov 17, 2009 at 3:21 PM, Bart Gauquie <bart.gauquie at gmail.com>
>> wrote:
>> > Hi all,
>> >
>> > I'm experimenting with Magma. See at:
>> > http://www.squeaksource.com/BkbagMagmaTesting/.
>> > Its just a very simple app which has basically an orderedcollection of
>> > todo's and an ordered collection of users. (each with 4 fields on it).
>> > The transparancy of Magma, is something i like very much.
>> > However, i'm also trying out the levels of performance Magma can offer.
>> > If i add 50 todo's and 25 users and i print them in a seaside
>> application it
>> > takes about 350 msecs to render the page. If i render the same page with
>> an
>> > in memory version the same request takes about 10 msecs to render the
>> page;
>> > which is a 340 msec overhead in magma.
>> > I have a 2.86 quadcore and i'm running locally 2 images. One with the
>> > database server in it; one with the seaside client application. The
>> client
>> > application creates one magma mession for each seaside session.
>> > To my opinion, 340 msecs not at all that great a performance. But I'm
>> not
>> > sure what i can expect of the magma performance, and if i have
>> configured it
>> > correctly. Is this kind of overhead normal? Because if i read the
>> > http://wiki.squeak.org/squeak/5606 performance page, i find that under
>> > Remote baseline (loopback address to same computer = no network
>> latency),
>> > following timings:
>> > readTests
>> > peakRefreshRate : 78.6898342320751 per second.
>> > singleObjectRead : 280.8315010993404 per second.
>> > oneThousandElementArrayRead : 19.93620414673046 per second.
>> > oneThousandElementArrayOfObjectsRead : 9.98629332289015 per second.
>> > oneMillionObjectPointersRead : 0.278357689631176 per second.
>> > oneThousandLevelsDeepRead : 8.30860534124629 per second.
>> > are a lot faster than the ones i'm experiencing.
>> >
>> > In attachment you find where the app is spending time in in the tally i
>> > performed on a request.
>> > The most time is spent in
>> >   |237 ProcessorScheduler class>>idleProcess
>> > I suppose that this is time the client is waiting for the server: is it
>> > normal that 2/3 of the time is server time,
>> > I've already tried some of the readstrategies, described at:
>> > http://wiki.squeak.org/squeak/2638, but that did not help.
>> > I've also tried on a ubuntu linux machine, and on a windows machine,
>> both
>> > display the same level of performance.
>> > Thanks in advance for any advice.
>> > Kind regards,
>> > Bart
>> >
>> > _______________________________________________
>> > Magma mailing list
>> > Magma at lists.squeakfoundation.org
>> > http://lists.squeakfoundation.org/mailman/listinfo/magma
>> >
>> >
>>
>
>
>
> --
> imagination is more important than knowledge - Albert Einstein
> Logic will get you from A to B. Imagination will take you everywhere -
> Albert Einstein
> Learn from yesterday, live for today, hope for tomorrow. The important
> thing is not to stop questioning. - Albert Einstein
> The true sign of intelligence is not knowledge but imagination. - Albert
> Einstein
> Gravitation is not responsible for people falling in love. - Albert
> Einstein
>

-- 
imagination is more important than knowledge - Albert Einstein
Logic will get you from A to B. Imagination will take you everywhere -
Albert Einstein
Learn from yesterday, live for today, hope for tomorrow. The important thing
is not to stop questioning. - Albert Einstein
The true sign of intelligence is not knowledge but imagination. - Albert
Einstein
Gravitation is not responsible for people falling in love. - Albert Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/magma/attachments/20091124/ccb56eaa/attachment-0001.htm