All,
which connection times are "normal" for magma. I'm currently experiencing around 7 seconds for the server image to connect to the repository and 10-12 seconds to establish a session for the seaside frontend images.
I do not really care about the server - however having a user to wait for 10-12 seconds for the initial page/login is quite another story.
I'm currently using a base 3.10 image with r42alpha4 on a DualCore 2.4 Ghz Linux Machine.
Are these times "normal"?
CU,
Udo
On Sat, Feb 28, 2009 at 5:27 AM, Udo Schneider Udo.Schneider@homeaddress.de wrote:
I do not really care about the server - however having a user to wait for 10-12 seconds for the initial page/login is quite another story.
I'm currently using a base 3.10 image with r42alpha4 on a DualCore 2.4 Ghz Linux Machine.
Are these times "normal"?
I'm seeing the same, with r41.1. I'm expecting I'll have to do connection pooling to mitigate it, which isn't much of a problem - you usually have to do that with most databases anyway, but it would be good to know whether or not these times are typical, or if they're indicative of something wrong.
For me, it's 5 seconds connect time on a 2.3GHz Core II, and a full 20 seconds on my EeePC (which is what I tend to use for development - so finding a way to speed it up would be really useful).
Standalone vs Client / Server doesn't make much difference for me. I'm also on a 3.10 image - maybe it's worth trying 3.9 to see if that makes a difference.
Regards, Stuart
Stuart Herring wrote:
On Sat, Feb 28, 2009 at 5:27 AM, Udo Schneider Udo.Schneider@homeaddress.de wrote:
I do not really care about the server - however having a user to wait for 10-12 seconds for the initial page/login is quite another story.
I'm currently using a base 3.10 image with r42alpha4 on a DualCore 2.4 Ghz Linux Machine.
Are these times "normal"?
I'm seeing the same, with r41.1. I'm expecting I'll have to do connection pooling to mitigate it, which isn't much of a problem - you usually have to do that with most databases anyway, but it would be good to know whether or not these times are typical, or if they're indicative of something wrong.
For me, it's 5 seconds connect time on a 2.3GHz Core II, and a full 20 seconds on my EeePC (which is what I tend to use for development - so finding a way to speed it up would be really useful).
Standalone vs Client / Server doesn't make much difference for me. I'm also on a 3.10 image - maybe it's worth trying 3.9 to see if that makes a difference.
Regards, Stuart
Magma seasideHelper also includes a connection pool option, as used by gjallar.
To be honest there are so many options I am not sure they have all been tested. There are also some innovations I expected users to tell me don't work. (e.g. automatic instance migration)
I always expected to keep a shared readOnly session alive for early user browsing, and login validation. Which gives me time to fire up a full session when they actually decide to buy something.
Keith
Udo Schneider wrote:
All,
which connection times are "normal" for magma. I'm currently experiencing around 7 seconds for the server image to connect to the repository and 10-12 seconds to establish a session for the seaside frontend images.
I do not really care about the server - however having a user to wait for 10-12 seconds for the initial page/login is quite another story.
I'm currently using a base 3.10 image with r42alpha4 on a DualCore 2.4 Ghz Linux Machine.
Are these times "normal"?
CU,
Udo
In the magma seasideHelper there is a strategy for this... after the new user session has displayed the first page, it kicks off the startup process for the magma session. By the time the user clicks the login link, hopefully magma session for that user will be up and running.
Keith
Btw, in latest Gjallar 0.5 I rewrote the Magma pool. It is "different" and perhaps a tad simpler to follow. I had some issues with the earlier one - often got stuck in a Semaphore inside it when developing - ended up rewriting, it might have been an easy fix though.
The new one uses a different strategy/design - it has a running background allocator that allocates new Magma sessions when a session is popped from the pool. And you can tell it how many "ahead" it should have. Kinda like the earlier one, although different. :)
regards, Göran
Okay it sounds like crazy, but I will peform user test with kids using istoa client on XO laptops.
The connection to the server (a laptop, cable connected to a wifi access point) is done through wifi as it is the only network link to a XO laptop. The connection time is pretty long, next the remote use of the Magma database seems ok (performance and only one error).
So far it takes about 90s for a XO laptop to open a session to the Magma database. I have enclosed a MessageTally spyOn when the session is open. I will be happy to get some feedback about anything I could improve regarding this benchmark.
But any way running on the XO is pretty slow.
Hi Hilaire!
Here is a change you can make in Magma which will make session allocation about 5X faster. In the method:
MaClassIdManager>>#addClassDefinition
At the bottom, just before the return, you may see the following code:
answer superclassDefinition notNil ifTrue: [ self addClassDefinition: answer superclassDefinition ].
DELETE those lines of code.
This fix is in the upcoming r42beta1.
Regards, Chris
On Tue, Mar 3, 2009 at 12:07 PM, Hilaire Fernandes hilaire@ofset.org wrote:
Okay it sounds like crazy, but I will peform user test with kids using istoa client on XO laptops.
The connection to the server (a laptop, cable connected to a wifi access point) is done through wifi as it is the only network link to a XO laptop. The connection time is pretty long, next the remote use of the Magma database seems ok (performance and only one error).
So far it takes about 90s for a XO laptop to open a session to the Magma database. I have enclosed a MessageTally spyOn when the session is open. I will be happy to get some feedback about anything I could improve regarding this benchmark.
But any way running on the XO is pretty slow.
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Chris Muller wrote:
Hi Hilaire!
Here is a change you can make in Magma which will make session allocation about 5X faster. In the method:
MaClassIdManager>>#addClassDefinition
At the bottom, just before the return, you may see the following code:
answer superclassDefinition notNil ifTrue: [ self addClassDefinition: answer superclassDefinition ].
DELETE those lines of code.
This fix is in the upcoming r42beta1.
Regards, Chris
excellent news!
Keith
Hi Chris,
It is wonderful. The XO machine now only takes about 20s to open a session, and it is quite acceptable.
Hilaire
Le mardi 03 mars 2009 à 13:33 -0600, Chris Muller a écrit :
Hi Hilaire!
Here is a change you can make in Magma which will make session allocation about 5X faster. In the method:
MaClassIdManager>>#addClassDefinition
At the bottom, just before the return, you may see the following code:
answer superclassDefinition notNil ifTrue: [ self addClassDefinition: answer superclassDefinition ].
DELETE those lines of code.
This fix is in the upcoming r42beta1.
Regards, Chris
On Tue, Mar 3, 2009 at 12:07 PM, Hilaire Fernandes hilaire@ofset.org wrote:
Okay it sounds like crazy, but I will peform user test with kids using istoa client on XO laptops.
The connection to the server (a laptop, cable connected to a wifi access point) is done through wifi as it is the only network link to a XO laptop. The connection time is pretty long, next the remote use of the Magma database seems ok (performance and only one error).
So far it takes about 90s for a XO laptop to open a session to the Magma database. I have enclosed a MessageTally spyOn when the session is open. I will be happy to get some feedback about anything I could improve regarding this benchmark.
But any way running on the XO is pretty slow.
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
magma@lists.squeakfoundation.org
-
Chris Muller -
Göran Krampe -
Hilaire Fernandes -
Keith Hodges -
Stuart Herring -
Udo Schneider