Hi Manu, On Tue, Oct 20, 2026 at 11:29:55AM +0000, Manu Nicolas wrote: > Since session rates are accounted per thread group, the "rate-limit > sessions" check sums, for each group, the remaining budget computed > against the full configured limit. A frontend therefore keeps accepting > connections as long as any group stays below the limit: > > - with evenly loaded groups, the frontend accepts up to the limit > multiplied by the number of thread groups; > - when some groups receive no traffic, e.g. with "bind ... thread > 1/all" and several thread groups, the limit is never enforced. > > No explicit thread group setting is needed to be affected. Since 3.3, > the default "performance" cpu-policy creates one thread group per CCX > when neither "nbthread" nor "thread-groups" is set, and binds are > spread over all groups. On machines with several CCX, a frontend with > no thread-related setting may thus accept several times its configured > session rate. Setting "thread-groups 1" works around the issue. > > With "rate-limit sessions 100" and three thread groups, a local test > measured about 270 sessions/s on a bind using all groups, and more than > 21000 sessions/s on a bind restricted to the first group.
Iniitially I didn't understand how such a case would be possible, but seeing the changed code I now understand. The reason is that we were summing the permitted incoming connections per thread-group and using that as a limit so that those not used would continuously offer their budget. I agree with your fix. I just changed something in your reg-test, I've added this so that we don't run it on systems with less than two threads (think CI systems for example): feature cmd "command -v nproc && [ $(nproc) -ge 2 ]" We'll see if the test remains reliable over time, as event rate measurements are not always super-stable, and it could occasionally trigger false-positives. But that would be no big deal. Thanks, Willy
