Thanks Jeffrey for the explanation..!!! Now, I have clearly understood why the performance is not consistent over number of users. It is the look up time that is adding on every time. Regards Tejesh ________________________________________ From: freeradius-devel-bounces+tejesh.vijayakumar=lntinfotech.com@lists.freeradius.org [freeradius-devel-bounces+tejesh.vijayakumar=lntinfotech.com@lists.freeradius.org] On Behalf Of Jeffrey Hutzelman [jhutz@cmu.edu] Sent: Thursday, December 17, 2009 4:58 AM To: FreeRadius developers mailing list Subject: RE: Free Radius performance variation --On Wednesday, December 16, 2009 08:11:28 PM +0530 Tejesh Vijayakumar <Tejesh.Vijayakumar@lntinfotech.com> wrote:
Thanks Alan for the suggestion..
My main query was why the difference of 45 [125 auth/sec - 80 auths/sec]. The no of auths per sec is dropping at a fast rate as the number of users are increasing. How to make that consistent upto some point say for atleast one million users. [i.e auths/sec would be almost same for no of users upto one million users].
With a flat users file, or an unindexed or poorly-indexed database, the time it takes to look up a user is proportional to the number of users. If you have 10 times as many users, it takes 10 times as long to do each user lookup. You've said that when you multiply the number of users by 10, the time it takes to respond to a request increases by about 50%, and you're surprised that it slowed down so much. You should be surprised it hasn't slowed down _more_. If you want response time to be constant regardless of the number of users, you need to store the users in a data structure which has constant lookup time regardless of the number of users. Let us know if you come up with one; the best modern computer science can do with this problem is O(log n) lookup time (in practice, you can do better by observing that the number of users is not _really_ unlimited; some hash strategies may give you nearly constant lookup time). You'll see an improvement if you properly set up and maintain your SQL database, including creating the necessariy indexes, or store your users in a more efficient data structure, such as that used by the fastusers module. Both of these approaches have already been suggested by others. -- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu> Carnegie Mellon University - Pittsburgh, PA - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html ______________________________________________________________________ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________