> On 2 Jun 2017, at 07:20, Jim Jagielski <j...@jagunet.com> wrote: > >> On Jun 1, 2017, at 1:29 PM, Jim Riggs <apache-li...@riggs.me> wrote: >> >> Regardless, even worst case, we are looking at what, iterating 6 pointers >> instead of 3 or 10 instead of 5? We probably have some lower hanging fruit >> across the request lifecycle code to increase performance than saving some >> arithmetic on a handful of structs, no? ;-) >> > > Oh I agree... it just seems that we add overhead during the > normal and nominal case (everybody is up and available) and > that the overhead is worse the more workers we have. I am > personally OK with abnormal situations being slower.... > > And yeah, I also have never like the duplication that's inherent > in all the lbmethods, and so I really like it being simplified. > But I could never figure out a way to remove that without making > it more complex or slower. Last idea I had was to create some > sort of looping cpp MACRO to encapsulate it at some level :/
Yeah. Take a look at the callback version I submitted last night. It has reduced the code in the lbmethods to almost nothing. The find_best_*() functions just call ap_proxy_balancer_get_best_worker() with a small, quick callback function and then do a little housekeeping. Nothing else. BUT, this implementation makes it extremely flexible if someone want to create a complex lbmethod. It can do whatever special/custom things it wants to in its find_best_() function and/or in the is_best_() callback...or maybe it wants to implement its own iteration for finding usable workers and doesn't want to use ap_proxy_balancer_get_best_worker()'s logic at all. Just because the 3 existing lbmethods use that flow doesn't mean everything has to, but we removed a lot of duplicate code with a shared function for them (and future lbmethods?) to use. I think it's a big win for extensibility and simplification of the lbmethod interface.
