As you said, the external representation as a float is syntactic sugar.
But the patch breaks that. Someone enters in, for example, 2.50
and what's displayed in 250, instead of 2.50.
Since all this is normalized by how ldfactor is USED, the algos
still work, but are now more granular, which is what we wanted.
> On Oct 24, 2017, at 4:16 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
> 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...