On Tue, Oct 24, 2017 at 3:28 PM, Jim Jagielski <j...@jagunet.com> wrote:
> I don't understand this patch. It looks like we are no lingering externally
> representing ldfactor as a float (e.g.: 2.50). Is that right? If so,
> I'm not sure why...
It seems to me that ldfactor expressed as "float" is just syntactic
sugar, it's still an "int" in struct proxy_worker_shared.
The lbmethods' algorithms were previously given value between 1 and
100, and since 2.4.28 this value is effectively between 100 and 10000.
For, e.g. bytraffic, this changes the below computation a bit:
mytraffic = ((*worker)->s->transferred / (*worker)->s->lbfactor) +
((*worker)->s->read / (*worker)->s->lbfactor);
Meaning that we now have a granularity of 10KB (instead of previous
100B, max) before a balancer member can take over the previous one (I
wondered why several successive small requests were always reaching
the same backend...).
It's fine that users can now use decimal numbers between 1.0 and 10.0
(or still non-decimals between 1 and 100 as before, though they
probably shouldn't mix both), but it shouldn't change lbmethods
behaviour IMHO.
The other builtin lbmethods don't seem impacted though (they only sum
up lbfactor), so maybe we need something for bytraffic only...
