Hi Anthony,
On Tue, Feb 13, 2024 at 07:49:06PM -0500, Anthony Deschamps wrote:
> >From 3fc983b719bd4d8af80037c36e7032e0af383557 Mon Sep 17 00:00:00 2001
> From: Anthony Deschamps <anthony.j.descha...@gmail.com>
> Date: Tue, 13 Feb 2024 18:11:56 -0500
> Subject: [PATCH] MINOR: lb-chash: Respect maxconn when selecting a server
>
> This is useful in a situation where hash-balance-factor isn't quite
> optimal. For example:
>
> If we have two servers at times of low traffic, if server A has one active
> request and server B has
> zero, we might prefer that a second request for the same resource also be
> routed to server A; with
> hash-balance-factor set to anything less than 200, that request would
> routed to server B, causing it
> to dedicate resources to a resource that is already loaded/warm in server
> A. Meanwhile, at times of
> high traffic, we still want multiple servers to be able to share the load
> of highly used resources.
I like the idea, however we shouldn't do it by default IMHO, because for
many users, maxconn is just a way to avoid bursts on the servers and almost
does not inflict perceptible delays. Here it would result in a significant
increase of the miss ratio for caches having a small maxconn that's often
reached and that's not always desirable.
I'm wondering if we shouldn't just add a new type for "hash-type". There
are already "map-based" and "consistent", maybe we should coin a new term
here ("bounded-consistent" or something shorter and more explanatory) ?
Alternately adding a new option in the backend would be possible as well,
of course. It would just require a bit of doc and explain that it only
applies to consistent hashing.
Thanks,
Willy
