You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by jean-frederic clere <jf...@gmail.com> on 2023/09/01 16:48:59 UTC
Re: balancers bybusyness, bytraffic and byrequest thread/process safe issues
On 8/31/23 18:46, Rainer Jung wrote:
> Hi there,
>
> mod_jk for example uses such aging, but only for the non busyness case.
> busyness is meant to show the number of currently in-flight requests, so
> aging isn't a good fit there. Old load numbers are never part of
> busyness. But busyness is the mode that is most sensitive to the numer
> skew effects that JFC observed. Therefore that attempt to have more
> precise counting there.
Based on the mod_jk code, I have a PR:
https://github.com/apache/httpd/pull/383
>
> It makes sense for byrequests and bytraffic though. But in mod_jk we use
> a different byrequests algorithm. Not the original count and decrement
> system that Mladen introduced but instead a count and age system.
>
> The aging for byrequests and bytraffic could be hooked on mod_watchdog
> which is nice, because we would not need to run it as part of normal
> request handling.
I will look to the age() and other to see how to use it with byrequests
and bytraffic.
>
> Another thing that comes to my mind is (graceful) restart handlingan
> bybusyness. It might make sense to clear the numbers in case of such an
> event.
>
> Best regards,
>
> Rainer
>
> Am 31.08.23 um 18:23 schrieb Jim Jagielski:
>> IIRC, the goal of having an "aging" function was to handle this exact
>> kind of thing, where values could be normalized over a long period of
>> time so that old entries that may skew results are not weighted as
>> heavily as new ones.
>>
>>> On Aug 30, 2023, at 11:19 AM, jean-frederic clere <jf...@gmail.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> All the balancers have thread/process safe issues, but with
>>> bybusyness the effect is worse, basically a worker may stay with a
>>> busy count greater than zero even no request is being processed.
>>>
>>> busy is displayed in the balancer_handler() so users/customers will
>>> notice the value doesn't return to zero...
>>>
>>> If you run a load test the value of busy will increase by time and in
>>> all the workers
>>>
>>> When using bybusyness, having pics in the load and later no much load
>>> makes the lowest busy workers used and the ones with a wrong higher
>>> value not being used.
>>>
>>> In a test with 3 workers, I end with busy:
>>> worker1: 3
>>> worker2: 0
>>> worker3: 2
>>> Doing the load test several time the buys values are increasing in
>>> all workers.
>>>
>>> I am wondering is we could end with something like:
>>> worker1: 1000
>>> worker2: 0
>>> worker3: 1000
>>>
>>> in this case bybusyness will send all the load to worker2 until we
>>> reach 1000 simultaneous request on worker2... Obvious that looks bad.
>>>
>>> How to fix that?
>>> 1 - reset the busy using a watchdog and elected (or transferred+read)
>>> unchanged for some time (using one of timeout we have on workers).
>>> 2 - warn in the docs that bybusyness is not the best choice for
>>> loadbalancing.
>>> 3 - create another balancer that just choose random a worker.
>>>
>>> --
>>> Cheers
>>>
>>> Jean-Frederic
> ยด
--
Cheers
Jean-Frederic