[Seaside] Summer of Code Project

[Ron Teitelbaum]

I've been chewing over a problem that takes this a step further.  I am
already one image per user but there is a lot going on in the server image,
enough that it affects the performance of seaside.  I'm considering both a
seaside image and a user background processor image to bring back some
seaside performance.  I'm already background threading and trying to push
the threads as low as possible but I can't seem to bring back acceptable
performance.

I guess it is very dependent on how you use seaside.

Ron Teitelbaum
 
> From: Avi Bryant
> 
> On 3/21/07, Boris Popov <boris at deepcovelabs.com> wrote:
> > Let's not forget that Avi's application is very well partitioned, so
> > taking down images and bringing them back up fits perfectly with a model
> > of 'image-per-application'. Most other applications out there do not
> > have such boundaries, so running as many images as possible close to
> > server capacity and balancing between them is probably a better thing to
> > do and any layer-7 load balancer should be capable of handling session
> > affinity properly, hence the value of inventing something new might be
> > reduced.
> 
> Even if you have a shared database between all your users (say, you
> use GLORP to access a single RDBMS), I think it's still valuable to
> keep each customer isolated in their own image (and if you're doing
> that, bringing them up and down all the time is the only way not to
> fill up your server memory too quickly).  That way anything that
> happens to one customer - an infinite loop chewing up resources, a
> #halt you add in a debugging session, a rollout of an experimental new
> feature - doesn't affect anyone else.  What you're describing is
> certainly simpler, but I do love my thousands of images...
> 
> Avi
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside