tree b25e931511bef9206ae213711f87e9f771be5e68
parent 8c855f6cff6864be423e9c18d98b0c2ac99486fb
author Willy Tarreau <w@1wt.eu> 1603379947 +0200
committer Willy Tarreau <w@1wt.eu> 1603384225 +0200
encoding latin1

MEDIUM: fwlc: re-enable per-server queuing up to maxqueue

Leastconn has the nice propery of being able to sort servers by their
current usage. It's really a shame to force all requests into the backend
queue when the algo would be able to also consider their current queue.

In order not to change existing behavior but extend it, this patch allows
leastconn to elect servers which are already full if they have an explicitly
configured maxqueue setting above zero and their queue hasn't reached that
threshold. This will significantly reduce the pressure in the backend queue
when queuing a lot with lots of servers.

A test on 8 threads with 100 servers configured with maxconn 1 jumped
from 165krps to 330krps with maxqueue 15 with this patch.

This partially undoes commit 82cd5c13a ("OPTIM: backend: skip LB when we
know the backend is full") but allows to scale much better even by setting
a single-digit maxqueue value. Some better heuristics could be used to
maintain the behavior of the bypass in the patch above, consisting in
keeping it if it's known that there is no server with a configured
maxqueue in the farm (or in the backend).