Optimal setup to handle large tps
Hi All, I was hoping for some advice from some of you: I have a requirement to deploy Freeradius to handle about 2M customers and of course I need to set up my environment optimally. I am aiming for about 1500 auths or accounting requests per second. 1.) Can Freeradius achieve that? Reading the performance blurb suggests it can? 2.) In order to achieve that, I guess it would be best to split auth and accounting to different servers? Agree? 3.) What is the optimal way to use the users file? As a gdbm/dbm data file or plain text file or something else? 4.) Any other advice would be appreciated! Thanks a lot! Kosie
Marius Booysen wrote:
I have a requirement to deploy Freeradius to handle about 2M customers and of course I need to set up my environment optimally. I am aiming for about 1500 auths or accounting requests per second.
That should be fine.
1.) Can Freeradius achieve that? Reading the performance blurb suggests it can?
I've run it at 40K packets/s for days straight.
2.) In order to achieve that, I guess it would be best to split auth and accounting to different servers? Agree?
Yes.
3.) What is the optimal way to use the users file? As a gdbm/dbm data file or plain text file or something else?
Wow. For 2M users? Don't use the "users" file. Use a real DB. Though I have tested the users file with many millions of users. It uses a lot of memory, but it works. The server puts the entries into a hash table internally. So it has the same performance for 1 user, or 2M users.
4.) Any other advice would be appreciated!
Do lots of tests. Alan DeKok.
On Fri, Oct 26, 2012 at 4:51 PM, Marius Booysen <marius.booysen@eircom.net> wrote:
I have a requirement to deploy Freeradius to handle about 2M customers and of course I need to set up my environment optimally. I am aiming for about 1500 auths or accounting requests per second.
1.) Can Freeradius achieve that? Reading the performance blurb suggests it can?
Yes, but be very, very careful during design phase of your solution. Get experts to help you if you can. For example, 1500 auth or acct/sec for 2M users would probably corressponds to ... what, 15-30 minutes accounting interim update interval? While it's very tempting to have near-real-time-enough usage update for users, the cost might be too great. You could probably lower that to 1 - 3 hour interval, and still find it acceptable from business-case perspective, while greaty reducing the burden on your backend. Another example. 1500 packets per sec would roughly means your backend (e.g. db) should be able to handle that ammount of read/write transaction combined, multiplied by (roughly) anywhere from 2 - 10 times (depending on your exact config). Reads for FR are usually "cheap" enough (courtesy of cache and index), but writes are expensive. And even 3k write transaction / sec is no joke. If you use a db backend, make sure you have a qualified dba and sysadmin to design a suitable solution. Hint: if they offer something with only 4-10 disks in RAID 5/6 configuration for that amount of workload, it's usually an early sign that they're not qualified to do the job. -- Fajar
participants (3)
-
Alan DeKok -
Fajar A. Nugraha -
Marius Booysen