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 | [EMAIL PROTECTED] tel. +31 (0)70 3906153 | http://www.e-advies.info -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
