Peter Nixon wrote:
While there IS a difference in speed between writing to an on-disk spool and your method (in memory queue) our method is "correct" and a dedicated disk (or raid set) is more than fast enough to keep up with thousands of requests per second. (I haven't benchmarked it recently but I suspect we are in 100K requests per second territory here depending on disk spindle speed, filesystem and cache configuration)
To put it another way, if a system doesn't have to be correct, you can make it run as fast as you want. Never underestimate that speed of a process that does "exit 0". It's not correct, but *man* is it fast!
Basically a queue of more than a second (or the timeout configured on your NAS) is worse than sending an Authentication reject to a couple of users as the whole thing just snowballs! An Auth queue only helps in the case where you have a huge peak of requests that cannot be serviced simultaneously but CAN be serviced quicker than the configurable timeout of your NAS. If you continually have a deep queue then you need to increase the speed of your backend.
The CVS head tries to be a little smarter. The priority is: a) replies from proxies (i.e. ongoing requests) b) requests with State attribute (i.e. EAP) c) everything else. This means that people get to finish their authentications.
I would be interested to see you run a benchmark to show that your algorithm for dealing with newest Auth request first is actually a performance gain in a high load environment. (I suspect that it will make very little difference compared with out caching system) If it does make a considerable difference, then of course we would consider adding a similar feature to FreeRADIUS. (ie. Please prove to us that what you have done is actually better!)
Dealing the the newest request first is *bad*. FreeRADIUS puts requests into a queue, and discards requests from the queue if it determines that they've timed out, or that the NAS has given up on them. Priority (or time-based) queues stabilize networks. FILO queues do not. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog