> On 1 Jun 2017, at 15:25, Yann Ylavic <ylavic....@gmail.com> wrote: > > On Thu, Jun 1, 2017 at 10:22 PM, Yann Ylavic <ylavic....@gmail.com> wrote: >> On Thu, Jun 1, 2017 at 7:29 PM, Jim Riggs <apache-li...@riggs.me> wrote: >>>> On 1 Jun 2017, at 07:55, Jim Jagielski <j...@jagunet.com> wrote: >>>> 2. I understand the logic behind creating the arrays, but doesn't >>>> this increase the overhead. We go thru the full list of workers >>>> one time, and then go thru the list of avail works and spares >>>> right after that. Assume that all workers are available; doesn't >>>> it mean we go thru that last 2x? >> [] >>> >>> The only way I can think of to avoid this without going back to >>> duplicating code across lbmethods, which I would argue is worse, is >>> to maybe have the lbmethod provide a callback function and context >>> pointer to ap_proxy_balancer_usable_workers() that gets called during >>> the loop iteration to pick the best member in flight. >> >> Couldn't a simple 'best' for ap_proxy_balancer_usable_workers() make >> it return a single entry? > > ... a simple 'best' *flag* (as argument) ...
I'm not sure I follow what this flag would be. The lbmethod would somehow have to tell ap_proxy_balancer_usable_workers() how to pick the best worker (e.g. by comparing the number of bytes sent or the number of requests processed). I'm not sure how that information could be passed as a flag unless we baked the behavior of byrequests, bybusyness, and bytraffic into ap_proxy_balancer_usable_workers(). But then how would we allow for plugging in additional lbmethods? >> >> By the way, retrieving ap_proxy_retry_worker() via an OPTIONAL_FN >> looks unnecessary since it's implemented in the exact same >> "proxy_util.c" file. LOL! That's a copy-paste remnant from when I had that function in a different file originally. Patch updated. Thanks for catching it!
