On Dec 5, 2014, at 5:21 AM, Baptiste <bed...@gmail.com> wrote: > > On Thu, Dec 4, 2014 at 11:50 PM, Daniel Lieberman > <dlieber...@bitpusher.com> wrote: >> We have a situation where our app servers sometimes get into a bad state, >> and hitting a working server is more important than enforcing persistence. >> Generally the number of connections to a bad server grows rapidly, so we've >> set a maxconn value on the server line which effectively takes a server out >> of the pool when the bad state occurs. >> >> If we fill up the connection slots, the server is almost definitely bad, so >> we'd rather not queue at all. Since maxqueue 0 means unlimited, it looks >> like the minimum queue size is 1. Is that right? Is there any way to >> enforce a redispatch whenever we're at maxconn, without any connections >> getting queued? >> >> Thanks, >> -Daniel > > > hi Daniel, > > We can do this :) > I just need to know how you do persistence currently. > Please send us your simplest frontend and backend configuration. > > Baptiste
We do cookie-based persistence, but also use balance source to use consistent backends on browsers which don’t support cookies (relevant for a significant fraction of the mobile users of this app). (In our case, switching app servers results an annoying UI quirk, but doesn’t break the session.) Here’s one of the relevant fe/be configs (lightly sanitized): frontend service1 bind 1.2.3.4:80 bind 1.2.3.4:81 accept-proxy bind-process 1 default_backend service1 backend service1 bind-process 1 balance source hash-type consistent wt6 avalanche option forwardfor option http-server-close option http-pretend-keepalive option httplog option httpchk GET /healthCheck.htm HTTP/1.1\r\nHost:\ example.com cookie SERVERID insert indirect server app1 app1:8080 cookie app1 maxconn 25 maxqueue 5 weight 100 check server app2 app2:8080 cookie app2 maxconn 25 maxqueue 5 weight 100 check [and many more app servers] Thanks, -Daniel
