Hi Pavlos! On Sat, Sep 12, 2020 at 11:45:12AM +0200, Pavlos Parissis wrote: > Hi old friends!, > > Is in the roadmap the addition of a circuit breaking which adapts its > settings using real-time data? > I believe we discussed this in the last HAProxyConf with a group of people, > but I don't remember if there were > , back then, concrete plans to work on it. > > I know that something similar can be accomplished by using agent check, but > IMHO it less ideal. > - watch > https://www.youtube.com/watch?v=CQvmSXlnyeQ&list=PLj6h78yzYM2O1wlsM-Ma-RYhfT5LKq0XC&index=21 > > - read > https://www.envoyproxy.io/docs/envoy/v1.15.0/configuration/http/http_filters/adaptive_concurrency_filter
Yep as you say we can indeed already do it using agent checks. I know it's not ideal, but what matters to me is that it indicates we already have the required core functionalities to do something like this. The proper way to implement such a mechanism is by using feedback reaction, similar to how MPPT solar panel controllers work: you never know if you're sending enough load to keep the servers busy, so you constantly need to try to send a bit more to see if any service degradation occurs or not. The degradation happens by response time suddenly becoming affine to the number of concurrent requests. Then the decision of where to stick needs to be made based on the choice of lower latency (bottom of curve) or higher bandwidth (top of curve). A simpler approach would consist in having a setting indicating how much extra response time is acceptable compared to the measued optimal one. I also think that it remains important to let the user configure lower and upper bounds that guarantee safe operations. And that's typically what could be done using the minconn and maxconn values. Instead of using the backend's fullconn setting we would rely on a response time measurement. Or maybe that could be the right opportunity for splitting connection concurrency from request concurrency, keeping connections for the hard limits and using request concurrency for softer limits. There's no such ongoing work that I'm aware of but that has always been a subject of interest to me (I even wrote down the algorithm to compute weights by measured response times using a low-pass filter a decade ago but I lost my notes and never felt like doing work again). So if anyone is interested in this subject, we can continue this conversation till we reach something that looks like a possible design roadmap. Cheers, Willy
