FreeRADIUS performance information (tuning, benchmark)
I'm running FreeRADIUS on a PC with a dual CPU of 2 GHz and 2 GB of RAM. It is working with PostgreSQL database. When I perform tests with radperf, running : radperf -s -f ../users.csv -p 800 -a pap 10.3.1.1 auth radiussomething where users.csv file contains 10000 user names with password, I get this output: Total succeeded : 3811 Total failed : 6189 Total no reply : 0 Total time (s) : 10.588 Packets/s : 944 Response times: < 10 usec : 0 < 100 usec : 0 < msec : 0 < 10 msec : 1 < 0.1s : 3758 < s : 5897 < 10s : 344 < 100s : 0 (the result is a good one taking in account the packets amount processed per second - related to more tests that I did). I would need a sever able to manage a much greater amount of users ( > 50000, up to 1000000). But for now I'm interested how to get the server working well with ~(50000<->100000) users. What configuration do I need for this (I mean hardware configuration)? What are the best recommended improvements that should be done? Would JRadius module help on improving performance? (I'm not familiar about JRadius). Thanks for any suggestions. N.B. In attachment you have the important part from output of running radiusd -XXX together with with radperf.
On 24/07/12 13:26, Andrei Petru Mura wrote:
I'm running FreeRADIUS on a PC with a dual CPU of 2 GHz and 2 GB of RAM. It is working with PostgreSQL database. When I perform tests with radperf, running :
radperf -s -f ../users.csv -p 800 -a pap 10.3.1.1 auth radiussomething
where users.csv file contains 10000 user names with password, I get this output:
Total succeeded : 3811 Total failed : 6189 Total no reply : 0 Total time (s) : 10.588 Packets/s : 944 Response times: < 10 usec : 0 < 100 usec : 0 < msec : 0 < 10 msec : 1 < 0.1s : 3758 < s : 5897 < 10s : 344 < 100s : 0 (the result is a good one taking in account the packets amount processed per second - related to more tests that I did). I would need a sever able to manage a much greater amount of users ( > 50000, up to 1000000). But for now I'm interested how to get the server working well with ~(50000<->100000) users.
The number of users isn't too important, I suspect. What matters is the authentication rate (number of auths/sec) and the accounting rate (acct/sec). You also need to ensure your SQL database can reply sufficiently quickly. This might depend on the number of users, since SQL query performance is a complex mixture of table size, indexing and load. 1000 auths/sec is quite a lot. It implies you need to perform 1000 SQL queries/sec (at LEAST). Try this: convert your SQL users into a "users" text file, like so: username Cleartext-Password := "password" ...and disable SQL, then re-run the test. I think it will perform a lot better. If so, then you know that the bottleneck is SQL, and that you should focus your efforts there.
What configuration do I need for this (I mean hardware configuration)?
You should really have >1 server, for resilience if nothing else. If you are using SQL you will need fast disks, with a big cache.
What are the best recommended improvements that should be done? Would JRadius module help on improving performance? (I'm not familiar about JRadius).
I seriously doubt it. Why do you think JRadius would help?
On 24 Jul 2012, at 13:49, Phil Mayers wrote:
On 24/07/12 13:26, Andrei Petru Mura wrote:
I'm running FreeRADIUS on a PC with a dual CPU of 2 GHz and 2 GB of RAM. It is working with PostgreSQL database. When I perform tests with radperf, running :
radperf -s -f ../users.csv -p 800 -a pap 10.3.1.1 auth radiussomething
where users.csv file contains 10000 user names with password, I get this output:
Total succeeded : 3811 Total failed : 6189 Total no reply : 0 Total time (s) : 10.588 Packets/s : 944 Response times: < 10 usec : 0 < 100 usec : 0 < msec : 0 < 10 msec : 1 < 0.1s : 3758 < s : 5897 < 10s : 344 < 100s : 0 (the result is a good one taking in account the packets amount processed per second - related to more tests that I did). I would need a sever able to manage a much greater amount of users ( > 50000, up to 1000000). But for now I'm interested how to get the server working well with ~(50000<->100000) users.
The number of users isn't too important, I suspect.
What matters is the authentication rate (number of auths/sec) and the accounting rate (acct/sec).
You also need to ensure your SQL database can reply sufficiently quickly. This might depend on the number of users, since SQL query performance is a complex mixture of table size, indexing and load.
1000 auths/sec is quite a lot. It implies you need to perform 1000 SQL queries/sec (at LEAST).
I'm not sure this is accurate given the number of failed requests, i'd investigate that then re-run the tests. -Arran
On 24/07/12 13:57, Arran Cudbard-Bell wrote:
1000 auths/sec is quite a lot. It implies you need to perform 1000 SQL queries/sec (at LEAST).
I'm not sure this is accurate given the number of failed requests, i'd investigate that then re-run the tests.
Ah, I didn't spot the "failed" count.
On Tue, Jul 24, 2012 at 01:49:27PM +0100, Phil Mayers wrote:
On 24/07/12 13:26, Andrei Petru Mura wrote:
radperf -s -f ../users.csv -p 800 -a pap 10.3.1.1 auth radiussomething ... < 0.1s : 3758 < s : 5897 < 10s : 344 ... I would need a sever able to manage a much greater amount of users ( > 50000, up to 1000000).
The number of users isn't too important, I suspect.
Number of rows shouldn't matter much (O(log N)) for database. It may matter for radperf, but you don't need to have _all_ of your users in users.csv for this.
Try this: convert your SQL users into a "users" text file, like so:
username Cleartext-Password := "password"
...and disable SQL, then re-run the test.
Exactly. I would have suggested to test without SQL overhead myself. Then you can compare the result to PostgreSQL (and probably, to other DBs, like MySQL, Oracle/DB2, bdb/gdbm etc if you like). -- With best regards, xrgtn
Hi, you could look at PGSQL optimization - ensure that the table has the right indexes and the table is in cache etc.
Try this: convert your SQL users into a "users" text file, like so:
username Cleartext-Password := "password"
...and disable SQL, then re-run the test. I think it will perform a lot better. If so, then you know that the bottleneck is SQL, and that you should focus your efforts there.
.the use 'fastusers' module instead. it'll scream along. if i dont get 5-figure auths from such a box i'd be disappointed.
What are the best recommended improvements that should be done? Would JRadius module help on improving performance? (I'm not familiar about JRadius).
tweak your PGSQL, ensure you arent running any modules you dont need - eg the 'unix' module which will query /etc/passwd for every single request, ensure that no logging is blocking, ensure that accounting is buffered and not locking/blocking a thread, basically get the system in a working state and then tweak/optimise. alan
On 24/07/12 14:10, alan buxey wrote:
Hi,
you could look at PGSQL optimization - ensure that the table has the right indexes and the table is in cache etc.
Try this: convert your SQL users into a "users" text file, like so:
username Cleartext-Password := "password"
...and disable SQL, then re-run the test. I think it will perform a lot better. If so, then you know that the bottleneck is SQL, and that you should focus your efforts there.
.the use 'fastusers' module instead. it'll scream along. if i dont get 5-figure auths from such a box i'd be disappointed.
I thought the stock "files" module did the same thing now?
Hi,
I would need a sever able to manage a much greater amount of users ( > 50000, up to 1000000). But for now I'm interested how to get the server working well with ~(50000<->100000) users.
for what its worth, we deal with around 8000 users concurrently on an 802.1X connection (so all the EAP overheads etc) ...and the servers see around 10 auths/s so....scaling this up, 100 auth/s would map to around 80k users... alan
participants (5)
-
alan buxey -
Alexander Gattin -
Andrei Petru Mura -
Arran Cudbard-Bell -
Phil Mayers