Oops, scratch that success report... dst_conn seems to apply to all connections, not just the current front-end. And it doesn't take an argument. With multiple front-ends, I'm not sure how it can be used to put a limit on only one of them.
On Wed, Feb 25, 2009 at 10:52 PM, Michael Fortson <[email protected]> wrote: > I think we're missing connslots support until the next release (3.16 > is mentioned in the archives as the first that's going to have it). > Willy must be used to having it from testing the next version :) > > switched to dst_conn and gt -- worked great. Thanks Karl! > > > > On Wed, Feb 25, 2009 at 10:47 PM, Karl Pietri <[email protected]> wrote: >> its the -gt make it just gt. >> >> this is what i ended up going with: >> >> frontend priority_rails_farm xx.xx.xx.xxx:80 >> mode http >> option forwardfor >> acl priority_full dst_conn gt 4 >> use_backend rails_farm if priority_full >> default_backend priority_rails_farm >> >> the backend priority_rails_farm has 4 servers with maxconn 1 in it. >> >> -Karl >> >> On Wed, Feb 25, 2009 at 10:38 PM, Michael Fortson <[email protected]> >> wrote: >>> >>> When trying this, I get: >>> [ALERT] 056/063556 (24031) : parsing [/etc/haproxy/haproxy.cfg:290] : >>> error detected while parsing ACL 'nearly_full'. >>> [ALERT] 056/063556 (24031) : Error reading configuration file : >>> /etc/haproxy/haproxy.cfg >>> >>> (haproxy version 1.3.15.7) >>> >>> source: >>> acl nearly_full connslots(fast_mongrels) lt 10 >>> use_backend everything if nearly_full >>> >>> also tried: >>> acl nearly_full connslots(fast_mongrels) -lt 10 >>> use_backend everything if nearly_full >>> >>> >>> hrm... >>> >>> On Sun, Feb 22, 2009 at 12:00 PM, Willy Tarreau <[email protected]> wrote: >>> > On Sun, Feb 22, 2009 at 10:03:22AM -0800, Michael Fortson wrote: >>> >> That's really cool. I've been doing it with weighting, but this is much >>> >> nicer. >>> > >>> > it was proposed and developped by someone on the list (I don't remember >>> > whom right now) for exactly this purpose. >>> > >>> >> Am I right in assuming that in this example, when nearly_full is >>> >> triggered, >>> >> it will switch entirely to that? >>> > >>> > yes, back1 will get traffic only when it's not considered full, and >>> > back2 will get the excess traffic. >>> > >>> >> how does the balance between the two >>> >> backends happen in this instance? >>> > >>> > There's no balance. The second backend only receives overloads. See >>> > that as a cheap vs expensive pool of servers (or local vs remote). >>> > >>> >> Should you just repeat the definition of >>> >> the first backend within the second to go "wide" with the server >>> >> spread? >>> > >>> > Yes, this seems appropriate depending on your workload. Maybe you'll >>> > remove "maxqueue" from the second though. >>> > >>> > Hoping this helps, >>> > Willy >>> > >>> > >> >> >
