Hi all.
I'm not sure if this mail have reached the list, because yesterday was
https://www.haproxy.org/ not reachable, so I resend it.
Regards
Aleks
On 2026-10-31 (Sa.) 00:40, Aleksandar Lazic wrote:
Hi.
While testing a latency aware variant of "balance random" (an RFC will
follow), I noticed that the comparison of the draws is skipped more
often than expected. random(<draws>) draws the servers on the
consistent hash ring with replacement, so a draw can return the best
server found so far. There is nothing to compare then, and the draw is
lost. With 4 servers and 2 draws, this happens for one choice out of
four, which then behaves like random(1).
The first patch draws again in this case, at most <draws> extra times
so that a farm with a single usable server does not loop. It is a few
lines in get_server_rnd(), plus one sentence in the documentation.
Measured locally with ideal servers (fixed delays, 30000 requests after
a warm-up), share of the requests sent to the slow servers:
farm random(2) before -> after
4 servers, 1 at 50ms 8.73% -> 5.16%
8 servers, 2 at 50ms 7.5% -> 6.80%
The second patch documents the other source of unevenness I found:
with the default weight of 1, each server only gets 16 points on the
ring, so the shares of the servers vary between about 2% and 4% with
32 servers. The same higher weight for all servers, such as 100, makes
them almost even. I only documented it, as changing the number of
points would change the distribution of the existing setups.
I would be glad about any feedback, also if you would prefer to keep
the current behavior of random for some reason I did not think of.
Regards,
Aleksandar
Aleksandar Lazic (2):
MINOR: backend: don't waste the draws of random on the same server
DOC: config: explain the effect of the weights on random's draws
doc/configuration.txt | 13 +++++++++++++
src/backend.c | 11 +++++++++++
2 files changed, 24 insertions(+)
