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
2009/11/17 Bart Gauquie bart.gauquie@gmail.com:
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.
Do you create a new magma session per request, or using already existing session? Opening a session normally takes some time, because of client/server handshaking, but once session is ready to go, i would expect better performane.
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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
I'm using a magma session for each seaside session. The creation of the magma session takes 2 - 3 seconds, which is fine.
So on each request i'm reusing an existing magma session.
On Tue, Nov 17, 2009 at 11:01 PM, Igor Stasenko siguctua@gmail.com wrote:
2009/11/17 Bart Gauquie bart.gauquie@gmail.com:
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.
Do you create a new magma session per request, or using already existing session? Opening a session normally takes some time, because of client/server handshaking, but once session is ready to go, i would expect better performane.
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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
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 correctly. Is this kind of overhead normal? Because if i read the http://wiki.squeak.org/squeak/5606 performance page, i find that under ... are a lot faster than the ones i'm experiencing.
Weuse Magma exentivly and get the performance you are expecting. Magma read performance is heavily influenced by the read strategy, which is how *deep* into and object tree gets returned whenever an object is agitated.
Set the read strategy for your application to ensure that the correct depth of object is returned. Otherwise only the original agitatd object is returned in the buffer with proxies in each instance variable. Agitating any variable will result in a separate read request.
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@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
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@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@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
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@gmail.comwrote:
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@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@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@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
Hi again,
On Tue, Nov 24, 2009 at 4:54 AM, Bart Gauquie bart.gauquie@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
magma@lists.squeakfoundation.org
-
Bart Gauquie -
Brent Pinkney -
Chris Muller -
Igor Stasenko