On 05/11/2018 16:58, William A Rowe Jr wrote: > On Mon, Nov 5, 2018 at 7:48 AM jean-frederic clere <jfcl...@gmail.com > <mailto:jfcl...@gmail.com>> wrote: > > On 30/10/2018 13:53, Jim Jagielski wrote: > > As some of you know, one of my passions and area of focus is > > on the use of Apache httpd as a reverse proxy and, as such, load > > balancing, failover, etc are of vital interest to me. > > > > One topic which I have mulling over, off and on, has been the > > idea of some sort of universal load number, that could be used > > and agreed upon by web servers. Right now, the reverse proxy > > "guesses" the load on the backend servers which is OK, and > > works well enough, but it would be great if it actually "knew" > > the current loads on those servers. I already have code that > > shares basic architectural info, such as number of CPUs, available > > memory, loadavg, etc which can help, of course, but again, all > > this info can be used to *infer* the current status of those backend > > servers; it doesn't really provide what the current load actually > > *is*. > > > > So I was thinking maybe some sort of small, simple and "fast" > > benchmark which could be run by the backends as part of their > > "status" update to the front-end reverse proxy server... something > > that shows general capability at that point in time, like Hanoi or > > something similar. Or maybe some hash function. Some simple code > > that could be used to create that "universal" load number. > > > > Thoughts? Ideas? Comments? Suggestions? :) > > having the back-ends to provide the load they are able to handle > lbfactor (via w_lf or somethere similar. That requires the back-ends to > be able to send request to httpd balancer-manager handler. > > > Not really. I'd suggest a response header, travelling with each response > back to the balancer, which can be composed quickly enough to share > a play-by-play snapshot of the availability of that backend. This adds > next to no traffic and minimal cpu drain if composed cleanly. And it can > optionally be axed by the balancer in the response to the client.
The problem is that if there is no requests going to back-end the load-balancer won't know that the back-end is available again after a load peak. > > The last thing we want are the routing headaches of contacting an > ever-changing list one-or-many potential balancers. And we can't > rely on a dying lbmember to "check in" that it isn't functional. Since > the balancer must already start requests to the backend, having that > backend supplement the responses with its health status is simple. > > cping/cpong or options * allows check back-end nodes before sending requests. -- Cheers Jean-Frederic
