httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Riggs <>
Subject Re: Ideas from ApacheCon
Date Thu, 01 Jun 2017 20:48:01 GMT
> On 1 Jun 2017, at 15:25, Yann Ylavic <> wrote:
> On Thu, Jun 1, 2017 at 10:22 PM, Yann Ylavic <> wrote:
>> On Thu, Jun 1, 2017 at 7:29 PM, Jim Riggs <> wrote:
>>>> On 1 Jun 2017, at 07:55, Jim Jagielski <> 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!

View raw message