Hi, we noticed this, however the effect was not that dramatic, because of the canary deployment of new haproxy versions. That canary just filled the caches and after a couple of days the hit-ratio just got back to normal and we could continue with haproxy upgrade. Actually we didn't investigate this as a bug, but just assumed something changed in haproxy internals that slightly affected the hashing. ;)
I still vote for fixing and backporting. In our case we will just notice again a hit-ratio decrease during the next haproxy upgrade. I presume other users that have "huge/fragile" caching layers are always doing some kind of canary deployment of new haproxy versions. Kind regards czw., 16 paź 2025 o 10:17 Willy Tarreau <[email protected]> napisał(a): > Hi all, > > On Mon, Sep 08, 2025 at 04:36:11AM +0200, Willy Tarreau wrote: > > Hi Ilya, > > > > On Sun, Sep 07, 2025 at 10:20:26PM +0200, ???? ??????? wrote: > > > if commit "MEDIUM: lb-chash: Deterministic node hashes based on server > address" > > > introduces breaking change .... and nobody complained ... likely > customers > > > are tolerant to such commit (as well as reverting) > > > > Yes that's my point as well for these ones, my concern was really about > > the hypothetical ones who would have deployed starting from 3.0 without > > ever facing the change. > > > > For now I'm not getting any "please don't fix this", which tends to > confirm > > my suspicions that such are rare. > > OK so I'm going to merge the fix and backport it now. It will be better > for all future upgrades. > > Thanks for your insights, > Willy > > >
