On Sun, Apr 22, 2012 at 1:08 PM, Timmy <moonyhk@netscape.net> wrote:
On 2012-04-22 02:53 AM, Christiaan Rademan wrote:
Greetings everyone,
I previously had a post concerning authenticate over 2 million+ mobile subscriber users on FreeRadius. We did performance testing yet, failed but due to pressure from client we went a head with the migration.
Well, fail to plan, plan to fail. You can use radperf/radclient for the test.
The migration failed at this point, since the Radius Server could not hand out more than 25 IP addresses per second. Obviously this was due to slow database server / resources. FreeRadius was happy to hand out logins once the pool assignment was done on the GGSN.
I'd say it's because of the design for allocate-find query, not because the db itself is slow.
So I am wondering, I found a solution to the problem and we are now handing out IP addresses easily.. 5000+ accept-accept responses per second with framedipaddress included from a pool within SQL.
Do you mean "I found a solution" or "I'm looking for a solution"?
Quad Zeon, 4 core, 8 threads, 16gig ram runnning Ubuntu Linux. Is it possible to hand out that many ip addresses per second? :)
Sure.
The box is also running both the radiusd and mysql process using a standard storage engine. Not using NDB or anything special. Is this really an impossible task?
No. But then again, it kinda contradict your "I found a solution" stamement. If you found the solution, you won't have to ask, would you?
Maybe I can find out from our company if I may release the code we using to make this work.
I would really like to help improve the SQLIPPool module. Since the version we were using could only do 25/s now we are over 5000/s.
If you can, please contribute.
Migrate to IBM DB2. There is a source of DB2 driver inside freeradius source.
I doubt that would work. IIRC the problem is that the default sql query use impiicit locks (i.e. SELECT ... FOR UPDATE) to make sure the allocated IP addresses are absolutely unique. In my case I traded uniqueness for performance by using randomization instead (which, most of the time, succesfully allocate unique IP addresses to clients). Then again, I could be wrong. If you HAVE perform a real test, and are able to hand out several hundreds IP/sec using the default query by ONLY changing the db, let me know. -- Fajar