On 17.2.2026 16.09, Stefan Paetow via radiator wrote:
I have a situation where I run a server with a large farm size, but I am trying to keep the number of outgoing Radsec connections low. To my knowledge, if I have a farm size of 64, all 64 of those farm threads will eventually create a connection to the other server.
Yes, that's correct.
FreeRADIUS sets a limit of 16 threads and connections per client (per IP), and outgoing traffic seems to be handled by a single thread there. Radsecproxy is similar in behaviour to FreeRADIUS. We’d prefer not to have to ask the site in question to up their pool size in FreeRADIUS but rather limit our number of threads dealing with outgoing Radsec.
That's reasonable. Tens of connections from the same IP is quite high.
I suppose this would mean either: - A hidden feature (is there one)
I don't think so. The worker processes are quite independent from each other and can't automatically, for example, pass packets to designated forwarders.
- Running a separate farm (of let’s say 8) that deals only with outgoing Radsec, and having to fiddle our config to tell our 64-size farm to connect internally to the farm of 8 to deal with the traffic.
I'd consider this one of two options: the other is to check if there's soemthing in the current configuration that allows dropping the farm size to a smaller number. I guess you have already looked at the possible changes. Is it logging, DB lookups or something else that makes the througput per packet slow?
Is there any way around that? If not, is the latter what I would need to do? And is this something I should be able to do without complicated port assignments?
The latter, separate workers for outgoing RadSec, is likely the way to go unless there's something that can be done to speedup the current configuration which would allow reducing the farm size.
An option could also be Radiator 10 which is built differently and does parallel processing completely differently. It's made with Rust and has different architecture. It's faster and still catching up with features. We could arrange a demo to discuss if it could be a possibility.
Thanks, Heikki -- Heikki Vatiainen Radiator Software, makers of Radiator Visit radiatorsoftware.com for Radiator AAA server software _______________________________________________ radiator mailing list [email protected] https://lists.open.com.au/mailman/listinfo/radiator
