[Seaside] Call for help: Seaside performances

[Boris Popov]

That's a pretty neat way of doing it when you partition the application
in a predictable manner, be it the hostname or the url token. In our
case we'll just have a fat stateful load balancer in front of an army of
medium sized servers (multiple VMs across a few servers, actually) that
proxies requests round the pool for new sessions and to the matching
machine for existing sessions based on their session cookie (or _s
parameter, since we use both now), in which case scaling is achieved by
adding more machines to the pool and spreading the load evenly across.
You can also get away with doing simpler IP based load balancing in most
cases which saves you cycles on the balancer that are needed to extract
the session id and serve as an SSL proxy, exception being the clients
from networks where outside gateway keeps changing all the time, which
AOL used to do quite a bit, not sure about the state of things nowadays.

Cheers!

-Boris

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

boris at deepcovelabs.com

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: seaside-bounces at lists.squeakfoundation.org
[mailto:seaside-bounces at lists.squeakfoundation.org] On Behalf Of Avi
Bryant
Sent: Thursday, January 11, 2007 3:34 PM
To: The Squeak Enterprise Aubergines Server - general discussion.
Subject: Re: [Seaside] Call for help: Seaside performances

On 1/11/07, Ramon Leon <ramon.leon at allresnet.com> wrote:

> Yea... What he said! LOL, but seriously, anxiously awaiting that
write-up...
> I have to get the kinks worked out before the travel season hits and
the
> real load starts coming.

So, here's the basic idea.  Each image has a unique port assigned to
it.  When a request comes into apache, you do the following:

1. Map the URL (or for us, the HTTP_HOST) to the right port.
2. Check if that port is open.
3. If the port is open, proxy the request to that port.
4. If the port isn't open, start up the image, and keep watching the
port until it opens.  Then proxy the request to it.

Steps 1 and 2 can be done using a program as a RewriteMap
(prg:/usr/bin/...).  I have one that takes a hostname and returns,
say, "open123" or "closed345" or "none" depending on what port it
finds and whether it's open.  This is easy to match in a subsequent
rewrite rule.

Step 3 is done by a RewriteRule that uses the [P] flag and the dynamic
port returned by the RewriteMap.

Step 4 is done by a CGI which shells out to start the image, does a
busywait loop for the port to open and then (in our case) uses the
Ruby HTTP library to do the final proxy (this is slow but only
necessary on the first request).

The specifics are pretty dependent on environment but the general
strategy works well.

Avi
_______________________________________________
Seaside mailing list
Seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside