Will do! THX!
> On Jun 2, 2017, at 9:46 AM, Jim Riggs <[email protected]> wrote:
>
>> On 2 Jun 2017, at 07:20, Jim Jagielski <[email protected]> wrote:
>>
>>> On Jun 1, 2017, at 1:29 PM, Jim Riggs <[email protected]> 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.
>
