(RADIATOR) Threading support (again)

[John Morrissey]

Looking through the archives, it's been a long time since someone's kicked
the threading horse.

We've been running Radiator on a fairly substantial RADIUS installation (a
dozen or so machines in three locations across the United States) for
several years now, making use of an LDAP directory for account storage.
(Hugh or Mike, feel free to e-mail me privately if you need more
information.) Unfortunately, OpenLDAP libraries do not seem well behaved
when Radiator forks, although it's been a while since we've tried.

Our largest problem with a monolithic process is that we've had occasional
problems where device outages cause thousands of subscribers to
reauthenticate simultaneously. This overwhelms our authentication radiusd
instances, causing UDP network queues on that port to skyrocket, eventually
leading to a cascade failure that is obnoxious to recover from, to say the
least. Our RADIUS servers are by no means underpowered, but it's just not
cost-effective to maintain a huge (and otherwise idle) hardware pool just to
handle occasional huge spikes like this.

Additionally, we're starting to deploy machines with four CPU cores as their
price has dropped substantially. We like sticking to a fairly standard
configuration, so we'd like to avoid "wasting" hardware that Radiator will
never use (we have auth and accounting split into two Radiator instances).
We could run more radiusd processes on different ports or IP addresses, but
this seems wasteful and complex.

Lastly, we're looking at implementing simultaneous use restrictions and are
concerned that the state refresh (SNMP in some cases, locally implemented
interfaces to proprietary devices in others) will block radiusd excessively.
We're also looking at proxying to more customers, and are concerned that
unreachable or underperforming proxy destinations will cause the same
behavior.

We had considered implementing rate limiting to handle our first concern
above, but that doesn't get us anywhere with the others. To that end, I'm
toying with the idea of adding a new process model to Radiator somewhat akin
to Apache's prefork MPM, with a number of child processes (not threads)
running round-robin on the incoming UDP port or handling work directed at
them via some sort of IPC from a central request handler process.

I haven't dived into the code yet to see how non-trivial this will be, and I
thought I'd ask around here first to see what everyone's thoughts are. I
know that a threaded model hasn't been implemented due to alpha-quality
thread support in Perl, and I haven't looked into its current state yet.
That's part of the reason I'm keen on using separate worker processes
instead of threads.

thanks,
john
-- 
John Morrissey          _o            /\         ----  __o
jwm at horde.net        _-< \_          /  \       ----  <  \,
www.horde.net/    __(_)/_(_)________/    \_______(_) /_(_)__

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.