Right, sorry -- it's the backend connections I need to limit based on; the frontend splits to a few backends based on various request parameters, and only one of those will apply in this case.
I supposed I could have the current setup of: frontend acls backend1 backend2 changed to something like: frontend acls frontend2 - default backend2 backend1 backend2 ..seems like an extra bit of re-routing though. On Wed, Feb 25, 2009 at 11:05 PM, Karl Pietri <[email protected]> wrote: > from my testing and from the docs it says it only applies to the frontend > that it is defined in. > > -Karl > > On Wed, Feb 25, 2009 at 10:57 PM, Michael Fortson <[email protected]> > wrote: >> >> 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 >> >>> > >> >>> > >> >> >> >> >> > > >
