Hi Nenad, On Sun, Apr 17, 2016 at 12:05:04AM +0200, Nenad Merdanovic wrote: > This is very useful in complex architecture systems where HAproxy > is balancing DB connections for example. We want to keep the maxconn > high in order to avoid issues with queueing on the LB level when > there is slowness on another part of the system. Example is a case of > an architecture where each thread opens multiple DB connections, which > if get stuck in queue cause a snowball effect (old connections aren't > closed, new ones cannot be established). These connections are mostly > idle and the DB server has no problem handling thousands of them. > > Allowing us to dynamically set maxconn depending on the backend usage > (LA, CPU, memory, etc.) enables us to have high maxconn for situations > like above, but lowering it in case there are real issues where the > backend servers become overloaded (cache issues, DB gets hit hard). > --- > doc/configuration.txt | 3 +++ > include/proto/server.h | 8 ++++++++ > src/checks.c | 18 +++++++++++++++++- > src/server.c | 27 +++++++++++++++++++++++++++ > 4 files changed, 55 insertions(+), 1 deletion(-) > > diff --git a/doc/configuration.txt b/doc/configuration.txt > index c705a09..640c0f3 100644 > --- a/doc/configuration.txt > +++ b/doc/configuration.txt > @@ -10146,6 +10146,9 @@ agent-check > weight is reported on the stats page as "DRAIN" since it has the same > effect on the server (it's removed from the LB farm). > > + - An ASCII representation of a positive integer, followed by a single > letter > + 'm'. Values in this format will set the maxconn of a server. > +
Your patch looks fine but I'm a bit bothered by the choice of the syntax here which is neither really intuitive nor future-proof. I even suspect you had some head-scratching before coming to this. At least I'd have found it more natural to use "10c" than "10m" to specific a connection limit but anyway that's still something we might regret over the long term. Thus, what do you think about using a completely different syntax such as "maxconn:10" or "maxconn=10" ? It would allow to seamlessly extend the language without breaking compatibility with existing products. On a side note, there is something important to mention in the documentation which is a side effect of doing this that most people do not realize. It currently affects protocols like ICAP. It's the fact that when a server advertises a maxconn to all of its clients (here the load balancers), it ends up with N times the expected maxconn. Thus I think we must make it very clear that the advertised value must absolutely be understood as *per load balancer*. Maybe in the future we'll want to support different words depending on whether we advertise the total maxconn the server supports or the per-client one (for when front LBs know how many they are). Thanks, Willy
