If they have a Jsession id in the session table, they stick with their backend until the TTL expires. Nothing will supersede that. You can see the session table with poundctl.
The question was "how does pound determine which backend to pick"... and pound only makes any sort of decision when it doesn't have an existing session. If it doesn't have an existing session, then it's random based on priority. Either: 1) Dynscale=0 - Priority as specified by you in the pound config 2) Dynscale=1 - Priority as adjusted by pound based on past response times If you have 10 requests all come in right after you start pound, dynscale won't make any difference, because it won't have any data to use to adjust priorities. It'll be random. If you don't want sticky sessions, then don't set them. In that case, *every* request will be load-balanced, and dynscale will be more effective. You got a bad random distribution. That's all there is to it. But it's probably not indicative of all future outcomes. If in your environment every incoming request will have equal difficulty on your backends, you probably want a more linear load balance. (i.e. Round Robin) Pound doesn't currently do that, but it'd be as simple as changing rand_backend() to always return the backend object with the lowest n_requests. (Or if it were to be configurable, probably a separate function entirely to do RR, and then a selector in get_backend to choose the correct "Backend Selection Strategy" or something similar) Joe From: Brad Allison <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Thursday, July 28, 2016 at 11:36 PM To: "[email protected]" <[email protected]> Subject: Re: [Pound Mailing List] Re: how does pound determine which backend to pick? How would that work if I have my TYPE=COOKIE (JSessionID). Once the connections are bound by JSESSIONID they are bound and will not be released until we have been IDLE for more than the TTL value. So if I have 10 incoming connections and it sends 8 to BACKEND-1 and 2 to BACKEND-2, those sessions are basically locked until I restart pound. To my understanding, DynScale=1 would only work on new incoming Sessions.... On Thu, Jul 28, 2016 at 9:47 AM, Joe Gooch <[email protected]> wrote: Random, weighted by priority of each backend. See svc.c - rand_backend() and get_backend() If you want it to make a decision based on response time, turn on DynScale. (see manpage) ------ Joe From: Brad Allison <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Wednesday, July 27, 2016 at 5:11 PM To: "[email protected]" <[email protected]> Subject: [Pound Mailing List] Re: how does pound determine which backend to pick? I'd really like to know how pound picks the backend. Is it latency based? -b On Tue, Jul 26, 2016 at 6:19 PM, Brad Allison <[email protected]> wrote: I have two backends. I have pound set up to use Session Cookies (JSESSIONID) for determining stickiness. I have 10 incoming sessions (each with a unique JSESSIONID). 8 of them are assigned to the first backend. 2 are assigned to the second backend. Why? Why would it not assign them with a 50/50 load? Half to the first and half to the second. The backends already had load that was not even. One was slightly more busy than the other. But how does pound determine which backend to pick when a new session comes in? The problem is this is a heavy weight process, and with 8 of them on my first backend, it's going to melt my first backend, while barely touching the second one. And since I've got session affinity with JSESSIONID it's going to keep sending the first 8 to the first one and the other 2 to the second one. -b
