[Seaside] Apache Load Balancing with Seaside

Sven Van Caekenberghe sven at stfx.eu
Sat Nov 12 12:29:01 UTC 2016


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 <philippe.marschall at gmail.com> wrote:
> 
> On Sat, Nov 12, 2016 at 10:01 AM, jtuchel at objektfabrik.de
> <jtuchel at objektfabrik.de> 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
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



More information about the seaside mailing list