Kevin J wrote: > Well, Radius protocol is not just machine-to-machine issue. I think you > don't understand how request protocol can be simulated by hammering with > our tool. We have tested various protocols by this tool.
The people here do have some experience with RADIUS. Including performance testing. > Per our test results, radius can reach the limit of requests by > hammering easily but CPU was still low. We have various statistics on > all these. My point is that radius was not able to use full cpu > resource until reaching max number of handful requests. "limit of requests"? What does that mean? And "max number of handful requests"? As was said, RADIUS is a very low overhead protocool. A RADIUS server doing PAP can easily handle 10's of 1000's of packets/s to localhost. This rate drops significantly when the network is used, due to additional network overhead. > Your point with more clients does not make sense because we already > reached max reqeusts hammering by our tool and that was same regardless > of adding more clients under multi-threaded enviroment. The other issue is that you haven't said *what* tests you ran, or how you configured the server. "We did stuff, and it didn't work out as well as we thought... what's wrong?" Um.... we're not sure... How have you configured the server? What kind of authentication methods are you using? Where are the user's passwords coming from? What kind of policies have you implemented on the server? If the passwords are coming from an SQL database, then the packet rate will be limited by the SQL SELECT rate. The CPU on the RADIUS side will be pretty much idle, even at the limit of the SQL performance. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html