Re: Cistron-Radius Users
On Thu, 14 Mar 2002, Russell Coker wrote:
> On Thu, 14 Mar 2002 13:57, Emile van Bergen wrote:
> > Of course, it's hardly the radius server itself that is the bottleneck
> > here, but the backend database, especially if you're writing accounting
> > information. *That* tends to be the hardest on a RADIUS server, not
> > authentication.
>
> There is the issue of whether the RADIUS server is multi-threaded or forking,
> or if it does all database lookups synchronously.
Or neither, but a design based on pre-spawned childs for all operations
(such as database operations) that take some time to complete. Such as
OpenRADIUS, incidentally written by yours truly.
I think that's generally a better idea than multi-threading. Having
multiple threads in the same address space always adds complexity, and I
tend to avoid it unless I really can't.
FreeRADIUS modules also have to deal with module instantiation
themselves if you want to run multiple copies of a module. OpenRADIUS
uses Unix's standard facilities (copy-on-write) for that, which makes
them a lot simpler.
The server itself only has to keep track of all outstanding I/O
happening to and from modules in the background. The only performance
drawback is the pipe I/O instead of C calls, but that has the advantage
that you can write modules in other languages than C.
> If the RADIUS server can only have one database lookup outstanding at
> any time (such as Radiator) then it'll be quite slow, and minor issues
> such as a small amount of network congestion between the RADIUS server
> and the database server can really kill performance.
Of course. Does Radiator really handle all external operations
synchronously? Boy.
> Multithreaded servers such as FreeRADIUS don't have this problem and can
> deliver much greater performance.
If you're interested, see http://www.openradius.net for another
approach.
Cheers,
Emile.
--
E-Advies / Emile van Bergen | e-advies@evbergen.xs4all.nl
tel. +31 (0)70 3906153 | http://www.e-advies.info
Reply to: