Magma start

[Chris Muller]

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 at 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 at 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 at seaswork.com>
> wrote:
>
> >        I'm starting Magma in an image and see it has a delay of 15 seconds
> to
> > 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 at lists.squeakfoundation.org
>  http://lists.squeakfoundation.org/mailman/listinfo/magma
>
>