New feature in v3.1.x
aland at deployingradius.com
Wed Dec 2 00:59:02 CET 2015
I've just committed a new feature to the v3.1.x branch. It's called "queue_priority" for the thread pool.
The idea is to allow the administrator to control how the server behaves in overload conditions. When a back-end database goes down, or 10K users log in at once, the server can't process packets as fast as they come in. This is "overload".
The usual method of dealing with overload is to put the extra packets into a queue for later processing. But the question is, how should the queue be organized? In v3.0 and earlier, the queue had fixed behaviour. In v3.1.x, it is configurable.
The 3 options are:
order packets by when they are received
Note that replies from a home server
are ordered by when the *original*
packet came in, so they are prioritized.
Order by listener type
proxy > auth > acct > detail > coa
Packets from the same listener are
ordered by "time".
Order by ongoing EAP sessions.
EAP authentication takes multiple
rounds. This priority ensures
that EAP sessions which are "further along"
in the authentication process are
handled with a higher priority.
Packets with the same eap priority
are ordered by "default"
The "default" order is pretty much what was in 3.0 and earlier.
If anyone has suggestions for additional prioritization methods, I'd be interested in hearing them.
More information about the Freeradius-Devel