Summer of Code Project

It doesn't look like I'll have time to participate in GSoC this year,
but if I did, my project would have been Ballast: a load balancer for
Seaside applications.  Ballast would manage several Squeak VM's and
direct incoming requests at the appropriate image.  It would snapshot
images that remained idle for too long and bring them back up on
demand (this is based on Avi's description of how DabbleDB works).  It
would probably make sense to base this on some well-tested
load-balancing package and just add Seaside-specific functionality on
top of that.

Anyone who's looking for a project can feel free to use the idea
and/or the name.

--
Bill Atkins
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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.

My 0.02c,

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 3/21/07, Boris Popov <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Avi Bryant wrote:
you are really running +1,000 images for dabble db?

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 3/21/07, Brad Fuller <[hidden email]> wrote:

> you are really running +1,000 images for dabble db?

10,000+.  Not counting backups, of course.  But it's rare to have more
than 40 or so actually running at any one time.

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Interesting thought, indeed, but I'm struggling coming up with a good
way of identifying customers to pass control to respective images,
unless we direct them to use different URLs ala DabbleDB or have a
separate app fronting the login page to determine credentials that way,
neither of which would work very well here. Any other ways to skin it
you can think of?

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
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 _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 3/21/07, Boris Popov <[hidden email]> wrote:
> Interesting thought, indeed, but I'm struggling coming up with a good
> way of identifying customers to pass control to respective images,
> unless we direct them to use different URLs ala DabbleDB or have a
> separate app fronting the login page to determine credentials that way,
> neither of which would work very well here. Any other ways to skin it
> you can think of?

Nothing comes to mind, but what's wrong with the separate login app idea?

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

It's one more thing to deploy and maintain? ;) I guess I could make it
part of the same app with different entry point, got to think about it
some more.

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of Avi Bryant
> Sent: Wednesday, March 21, 2007 10:57 AM
> To: Seaside - general discussion
> Subject: Re: [Seaside] Summer of Code Project
>
> On 3/21/07, Boris Popov <[hidden email]> wrote:
> > Interesting thought, indeed, but I'm struggling coming up with a
good
> > way of identifying customers to pass control to respective images,
> > unless we direct them to use different URLs ala DabbleDB or have a
> > separate app fronting the login page to determine credentials that
way,
> > neither of which would work very well here. Any other ways to skin
it
> > you can think of?
>
> Nothing comes to mind, but what's wrong with the separate login app
idea?
>
> Avi
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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
 

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Avi Bryant wrote:
> On 3/21/07, Brad Fuller <[hidden email]> wrote:
>
>> you are really running +1,000 images for dabble db?
>
> 10,000+.  Not counting backups, of course.  But it's rare to have more
> than 40 or so actually running at any one time.
holy crap, how do you manage all that? How many images per server and
what's the memory on those servers? That sounds overkill for only 40
simultaneous. HAProxy must be your friend ;-)
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Couple of questions below...

        cheers,

Sebastian Sastre

 
If I understood right, that can be done only if every application is used by
one user or extremely low concurrence circunstances. Low as much as the
maximum concurrent users per image squeak can reasonabily manage. In such
way one can use lovely ImageSegments for persistance. But how we
horizontally scale an app supported by Squeak with 100 concurrent users?

> Avi
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 3/21/07, Sebastian Sastre <[hidden email]> wrote:

> If I understood right, that can be done only if every application is used by
> one user or extremely low concurrence circunstances. Low as much as the
> maximum concurrent users per image squeak can reasonabily manage. In such
> way one can use lovely ImageSegments for persistance. But how we
> horizontally scale an app supported by Squeak with 100 concurrent users?

No, this has nothing to do with persistence.  This is just about
assigning each user or small group of users their own copy of the
application in their own image.  These copies can all be of the
identical application and use the identical backend database.

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Il giorno mer, 21/03/2007 alle 09.18 -0400, Bill Atkins ha scritto:
Just for the record, we already have a load balancing proposal in our
list. But you ideas are interesting. And the name is even better!

        Giovanni

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Avi Bryant wrote:
> On 3/21/07, Brad Fuller <[hidden email]> wrote:
>
>> you are really running +1,000 images for dabble db?
>
> 10,000+.  Not counting backups, of course.  But it's rare to have more
> than 40 or so actually running at any one time.
in a related note, are you (Avi) going to make your Etech talk available
for those who can't make it?
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 3/21/07, Brad Fuller <[hidden email]> wrote:

> in a related note, are you (Avi) going to make your Etech talk available
> for those who can't make it?

One way or another, yes.  It's a tutorial, which means I expect it to
be mostly interactive rather than slides etc, but the basic material
will get posted.

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

You mean like this?
http://wiki.squeak.org/squeak/5956

On Mar 21, 2007, at 6:18 AM, Bill Atkins wrote:

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside