Hi Sebastian,
I'm starting Magma...
Are you using the new r41beta and experiencing slow image startups when sessions were left connected when the image was saved? If so, then yes, there is a new unfinished "feature" that can slow down the session reconnection process.
The feature is called a "super refresh" (actual method name is #refreshAll) where all persistent objects in the image are refreshed by the copies in the repository. This is actually necessary to have long-lived images; where you work in a remote repository, then disconnect for a time, then reconnect and resume work. While disconnected, the in-image persistent objects become stale as commits by other users continue to occur to the repository.
Although this new super-refresh should not be necessary for single-user repositories, it was doing it unnecessarily. I have put in an appropriate guard into this new beta which should improve connection times back to where they were in r40 for single-user repositories. The fix for remote repositories be in the next or a future beta.
The startup would be so problematic unless you plan to use it lazily as I was hoping to be able to. A solution for the startup delay would be solved by using a big magma server who is allways running and lots of clients use it. The problem with that is scale. I don't think one Magma server will scale as much as I need (mostly due to Squeak memory scaling). But I'm pretty confident N magma servers will do the job.
Yes, the scalability of a centralized service depends on its ability to decentralize. Magma can do that to some degree, but could still be improved. Just to clarify, there is a limit to the number of users a single Magma server can serve and still provide good response times. But you would reach this point long before exceeding a memory constraint of all but the smallest-configured (128MB RAM) machines. A *Seaside server*, however, employing one MagmaSession per client, would tend to be memory-constrained. My guess this is what you meant.
Regards, Chris
On Sun, Mar 30, 2008 at 3:41 PM, Sebastian Sastre ssastre@seaswork.com wrote:
The startup would be so problematic unless you plan to use it lazily as I was hoping to be able to. A solution for the startup delay would be solved by using a big magma server who is allways running and lots of clients use it. The problem with that is scale. I don't think one Magma server will scale as much as I need (mostly due to Squeak memory scaling). But I'm pretty confident N magma servers will do the job.
Sebastian Sastre
De: Rob Rothwell [mailto:r.j.rothwell@gmail.com] Enviado el: Domingo, 30 de Marzo de 2008 15:45 Para: Sebastian Sastre Asunto: Re: Magma start
On Sun, Mar 30, 2008 at 2:20 PM, Sebastian Sastre ssastre@seaswork.com wrote:
I'm starting Magma in an image and see it has a delay of 15 secondsto
start in in a centrino 1.8GHz. Is that time normal?
I spent Friday night and Saturday afternoon trying to do bulk loads of large of large database queries into objects.
It routinely took 20-25 seconds on a centino 1.8GHz in a compaq 6510b laptop to open a repository locally.
Then, it would take another 20 seconds or so to add a root object, which I did a lot while I was trying to figure out what I didn't understand!
So...no answers, but I can confirm your problem, I think!
Other than that, I haven't figured anything out yet...
Rob
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma