> > If I have the number of SQL connections say set to 10, then when I > > launch a large number of RADIUS requests the log files say that > > there isn't enough SQL connections and it seems to then reject the > > connection. So I get a few accepts and hundreds of rejects. > > Yes... because the SQL queries are taking too long. It's simple > math. > > The server gets 100 requests in a second, and if the SQL queries > take 1/10 of a second each, it will take 10 seconds to respond to all > of the requests. At which point, some will have timed out, and the > NAS will have sent even more. > > Fix your SQL database to be faster, or run it on a faster machine.
I have tried running it from a RAM disk with no noticable improvement. The machine it is running on is a 2GHz system, however the same system is the one generating the requests also. I will try moving the radius off onto a non local system and see how it behaves. > > How is this achieved? I thought that the RADIUS protocol only > > permitted 256 sessions, (well per connection)? > > There is no "connection" between NAS and RADIUS server. > > Read the RFC's for descriptions of how more than 256 requests from > one NAS are allowed. I have been reading through the RFC's I shall dig deeper. > > if I have less than 256 it rejects a lot of the requests. > > Because your SQL database is slow. Adding more SQL sockets means > that even more requests can *appear* to be handled. It doesn't solve > the underlying problem. Would switching to non-threaded increase performance for fewer connections? > > Any idea of timescale for this? > > Before 1.0. :) > > hanging back on responces to slow the sender down? > > That won't make any difference. Thats what I thought -- ----- Graeme Hinchliffe (BSc) Core Internet Systems Designer Zen Internet (http://www.zen.co.uk) ICQ 3842605 (link) Sales : 0870 6000 971 Fax : 0870 6000 972 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
