How fast can IP Pool SQL be? :) *a Shocker*

[Fajar A. Nugraha]

On Sun, Apr 22, 2012 at 1:08 PM, Timmy <moonyhk at 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