On 2013-7-21 18:16, Godbach wrote:
> On 2013-7-21 16:53, Willy Tarreau wrote:
>> Hi Godbach,
>>
>> That's quite a good analysis. I'm realizing that durnig the development
>> of the algorithm, the maximum weight was 255, and it was later
>> changed to
>> 256. The test code that was used for this is still in
>> tests/filltab25.c if
>> you're curious. It displays in which order servers are picked, and
>> applies
>> random weight changes on the fly.
>>
>> I carefully checked and for me we can set SRV_UWGHT_MAX to
>> SRV_UWGHT_RANGE.
>> It will have the effect of limiting the maximum number of servers a full
>> weight to 4095 instead of 4128 (so please update the doc for this).
>> It is
>> also used in the leastconn algorithm, and similarly, the effective max
>> number of connections per server without overflowing will be limited to
>> 1048575 instead of 1052688 (this is not a big issue).
>>
>> So yeah, please go ahead and send a fix for this by. Please also replace
>> 4128 with 4095 in the documentation!
>>
>> Best regards,
>> Willy
>>
>>
> Hi Willy,
>
> Do you mean that we set SRV_UWEIGHT_MAX to SRV_UWEIGHT_RANGE in function
> fwrr_queue_by_weight for roundrobin and similar function for leastconn:
>
> static inline void fwrr_queue_by_weight(struct eb_root *root, struct
> server *s)
> {
> s->lb_node.key = SRV_EWGHT_MAX - s->eweight;
> eb32_insert(root, &s->lb_node);
> s->lb_tree = root;
> }
>
> Since I have done this before I sent the first mail, but the result
> was still not as expected,
> I want to know that the check you have done was a real test not only
> code review. If so, I will
> do the test again later and send the patch if it works well.
>
Oh, I guess you meant that set SRV_EWGHT_MAX to SRV_EWGHT_RANGE,
not SRV_UWGHT_*.-- Best Regards, Godbach
