Apache Load Balancing with Seaside

> Hi there,
>
> we're finally at a stage where we need load balancing is not only needed but
> also needs to be a bit more fine-grained.
>
> So far, we've used Apache's mod_proxy_balancer with an byrequests balancing
> scheme and the simply Set Cookie, but this is not really distributing load
> in an even manner, because it simply does a round robin based on requests.
> Teh way I seem to understand this, this just sends every nth request to
> another backend, unless the sticky session cookie is there.
>
> This seems to have multiple problems in the context of Seaside:
>
> 1. each page render consits of dozens of requests, and at least 2 in case of
> the usual redirect/render cycle
>
> 2. So request != new seaside session and therefor not a good base for
> distribting load
>
> 3. It seems the Cokie as marker for stickyness is browser wide. Every new
> session started in teh same browser gets directed to the same seaside image
>
> So this starts to cause problems in our scenario because there is always one
> image (the first one in the http.conf) that handles most of the load, no
> matter how many images we add.
>
> I think I understand that URL encoding for the load balancer would fit much
> better for Seaside. What's even better is the fact that Seaside already uses
> the _s parameter to identify a session.
>
> So at first sight, I think it might be a good idea to use the _s parameter
> provided by Seaside as the URL parameter that is also used for session
> stickyness.
>
> This brings up a few questions:
>
> * Is this a good idea?
> * Has anybody tried?
> * How to configure this?
>
> The most important question, however, is this: would this be any better wrt
> workload distribution? I mean, how could we make sure the very first request
> gets redirected to a new image? My fear is that in the end this will still
> have the same problem: the initial sessions will still be mostly created by
> the same image all of the time. The only difference might finally just be
> the fact that we use URL parameters instead of Cookies and spend nights
> testing and stuff and end up with the same problems...
>
> Before you suggest using squid or the like, let's think about the basic
> problem: does squid do things differently? What mechanism there is so much
> better than counting requests, measuring bytes transferrred or such?
>
> So how do people solve this problem? Any ideas, hints, experiences are
> greatly appreciated

> On 12 Nov 2016, at 11:14, Philippe Marschall <[hidden email]> wrote:
>
> On Sat, Nov 12, 2016 at 10:01 AM, [hidden email]
> <[hidden email]> wrote:
>> Hi there,
>>
>> we're finally at a stage where we need load balancing is not only needed but
>> also needs to be a bit more fine-grained.
>>
>> So far, we've used Apache's mod_proxy_balancer with an byrequests balancing
>> scheme and the simply Set Cookie, but this is not really distributing load
>> in an even manner, because it simply does a round robin based on requests.
>> Teh way I seem to understand this, this just sends every nth request to
>> another backend, unless the sticky session cookie is there.
>>
>> This seems to have multiple problems in the context of Seaside:
>>
>> 1. each page render consits of dozens of requests, and at least 2 in case of
>> the usual redirect/render cycle
>>
>> 2. So request != new seaside session and therefor not a good base for
>> distribting load
>>
>> 3. It seems the Cokie as marker for stickyness is browser wide. Every new
>> session started in teh same browser gets directed to the same seaside image
>>
>> So this starts to cause problems in our scenario because there is always one
>> image (the first one in the http.conf) that handles most of the load, no
>> matter how many images we add.
>>
>> I think I understand that URL encoding for the load balancer would fit much
>> better for Seaside. What's even better is the fact that Seaside already uses
>> the _s parameter to identify a session.
>>
>> So at first sight, I think it might be a good idea to use the _s parameter
>> provided by Seaside as the URL parameter that is also used for session
>> stickyness.
>>
>> This brings up a few questions:
>>
>> * Is this a good idea?
>> * Has anybody tried?
>> * How to configure this?
>>
>> The most important question, however, is this: would this be any better wrt
>> workload distribution? I mean, how could we make sure the very first request
>> gets redirected to a new image? My fear is that in the end this will still
>> have the same problem: the initial sessions will still be mostly created by
>> the same image all of the time. The only difference might finally just be
>> the fact that we use URL parameters instead of Cookies and spend nights
>> testing and stuff and end up with the same problems...
>>
>> Before you suggest using squid or the like, let's think about the basic
>> problem: does squid do things differently? What mechanism there is so much
>> better than counting requests, measuring bytes transferrred or such?
>>
>> So how do people solve this problem? Any ideas, hints, experiences are
>> greatly appreciated
>
> Unless you run on GemStone/S you need sticky sessions because there is
> generally a lot session related state required to service requests.
> That state is image local.
> Making mod_proxy_balancer do sticky sessions is fairly trivial, simply
> add a route to the session id. Have a look at the
> WARouteHandlerTrackingStragety hierarchy in the Seaside-Cluster [1]
> package. Then you'll just need to make sure that requests without a
> session are evenly distributed across images.
> There are still issues left. First you can't dynamically add and
> remove images. Second when an image has more load than an other for
> whatever reason you can't tell mod_proxy_balancer to favour the less
> strained images for new sessions. mod_cluster allows you to do this,
> but I have only an incomplete and buggy implementation.
>
> [1] http://www.squeaksource.com/ajp.html
>
> Cheers
> Philippe
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Hi Joachim,
>
> Like Philippe says, you have to send all request of one session to the same image.
>
> What I currently do is the following in nginx:
>
> upstream my-seaside {
>    ip_hash;
>    server my-seaside-2:9090;
>    server my-seaside-2:9091;
>    server my-seaside-3:9090;
>    server my-seaside-3:9091;
> }
>
> server {
>    listen 443 ssl;
>    listen 80;
>    server_name ... ;
>
>    ssl_certificate ...;
>    ssl_certificate_key ...;
>
>    location /files {
>      alias /home/ubuntu/static-files/;
>      try_files $uri @seaside;
>      gzip on;
>      gzip_types application/x-javascript text/css;
>      expires 30d;
>    }
>
>    location / {
>      proxy_pass http://my-seaside;
>      add_header X-Server Pharo;
>    }
>
>    location @seaside {
>      proxy_pass http://my-seaside;
>      add_header X-Server Pharo;
>    }
> }
>
> This does 2 things:
>
> (1) it load balances (upstream) over 4 images (2 on 2 machines), using ip_hash - this needs no further configuration; the client's ip is hashed and all requests go to the same image (sticky); this is not optimal (there is some spreading but not load based), but it offers good availability (fail over in case a machine or image goes down).
>
> (2) it tries to resolve all of seaside's /files resources directly from the file system, if possible - this off loads those requests off seaside, making it do less work. [ see #deployFiles ]
>
> This seems to work well in practice.
>
> Sven
>
>> On 12 Nov 2016, at 11:14, Philippe Marschall <[hidden email]> wrote:
>>
>> On Sat, Nov 12, 2016 at 10:01 AM, [hidden email]
>> <[hidden email]> wrote:
>>> Hi there,
>>>
>>> we're finally at a stage where we need load balancing is not only needed but
>>> also needs to be a bit more fine-grained.
>>>
>>> So far, we've used Apache's mod_proxy_balancer with an byrequests balancing
>>> scheme and the simply Set Cookie, but this is not really distributing load
>>> in an even manner, because it simply does a round robin based on requests.
>>> Teh way I seem to understand this, this just sends every nth request to
>>> another backend, unless the sticky session cookie is there.
>>>
>>> This seems to have multiple problems in the context of Seaside:
>>>
>>> 1. each page render consits of dozens of requests, and at least 2 in case of
>>> the usual redirect/render cycle
>>>
>>> 2. So request != new seaside session and therefor not a good base for
>>> distribting load
>>>
>>> 3. It seems the Cokie as marker for stickyness is browser wide. Every new
>>> session started in teh same browser gets directed to the same seaside image
>>>
>>> So this starts to cause problems in our scenario because there is always one
>>> image (the first one in the http.conf) that handles most of the load, no
>>> matter how many images we add.
>>>
>>> I think I understand that URL encoding for the load balancer would fit much
>>> better for Seaside. What's even better is the fact that Seaside already uses
>>> the _s parameter to identify a session.
>>>
>>> So at first sight, I think it might be a good idea to use the _s parameter
>>> provided by Seaside as the URL parameter that is also used for session
>>> stickyness.
>>>
>>> This brings up a few questions:
>>>
>>> * Is this a good idea?
>>> * Has anybody tried?
>>> * How to configure this?
>>>
>>> The most important question, however, is this: would this be any better wrt
>>> workload distribution? I mean, how could we make sure the very first request
>>> gets redirected to a new image? My fear is that in the end this will still
>>> have the same problem: the initial sessions will still be mostly created by
>>> the same image all of the time. The only difference might finally just be
>>> the fact that we use URL parameters instead of Cookies and spend nights
>>> testing and stuff and end up with the same problems...
>>>
>>> Before you suggest using squid or the like, let's think about the basic
>>> problem: does squid do things differently? What mechanism there is so much
>>> better than counting requests, measuring bytes transferrred or such?
>>>
>>> So how do people solve this problem? Any ideas, hints, experiences are
>>> greatly appreciated
>> Unless you run on GemStone/S you need sticky sessions because there is
>> generally a lot session related state required to service requests.
>> That state is image local.
>> Making mod_proxy_balancer do sticky sessions is fairly trivial, simply
>> add a route to the session id. Have a look at the
>> WARouteHandlerTrackingStragety hierarchy in the Seaside-Cluster [1]
>> package. Then you'll just need to make sure that requests without a
>> session are evenly distributed across images.
>> There are still issues left. First you can't dynamically add and
>> remove images. Second when an image has more load than an other for
>> whatever reason you can't tell mod_proxy_balancer to favour the less
>> strained images for new sessions. mod_cluster allows you to do this,
>> but I have only an incomplete and buggy implementation.
>>
>> [1] http://www.squeaksource.com/ajp.html
>>
>> Cheers
>> Philippe
>> _______________________________________________
>> 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