[RADIATOR] Load testing radiator

Sat May 16 00:50:32 CDT 2009

Hugh,

Impressive gains with the FarmSize feature enabled!!

The numbers jumped high enough that I had to seek out better client
hardware and disabled most other activities on the servers to reduce
variables, resulting in improved numbers all around (e.g. both AMD &
Intel servers increased ~200 requests/second from their initial
baselines).  Unfortunately, it became evident during the tests that I
don't have available client capacity to max out the 8-core server.
Based on the results, I'm estimating an 8-core dual Xeon 5355 server can
reach 15K requests/second.

Comparison:

Dual AMD 275 (4 cores, 2.2Ghz, 1MB L2 cache)
No farm, 2400, 100% one core
Farm size 1, 2400, 100% one core
Farm size 2, 4600, 100% two cores
Farm size 3, 6400, 100% three cores
Farm size 4, 7200, ~90% four cores
Farm size 5+, ~7200, ~90% four cores

Dual Xeon 5355 (8 cores, 2.6Ghz, 4MB L2 cache)
No farm, 3200, 100% one core
Farm size 1, 3200, 100% one core
Farm size 2, 6100, 100% two cores
Farm size 3, 8200, 80% three cores
Farm size 4+, 8200, ~60% or less across multiple cores

Minor edit needed to keep track of requests per second per process:
/usr/bin/radiusd -- Line # 356
old:  print "Currently handling
new:  print "PID:$$ Currently handling

-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au] 
Sent: Friday, May 15, 2009 10:39 PM
To: Patrick, Robert
Cc: radiator at open.com.au
Subject: Re: [RADIATOR] Load testing radiator

Hello Robert -

I would be very interested to see what numbers you get with the new  
ServerFarm parameter in Radiator 4.4.

Simply adding something like this to the configuration file (depending  
on the number of cores available):

# ServerFarm to spawn multiple child processes
# NB: only supported on *NIX platforms

ServerFarm 5

Of course in typical production systems the bottlenecks occur  
elsewhere - usually the backend database.

Many thanks for sharing this information.

regards

Hugh

On 16 May 2009, at 11:17, Patrick, Robert wrote:

> Running the same tests with a slightly newer server (two quad-core  
> Intel
> Xeon CPU 5355 2.66Ghz processors) produces 2900~3000 requests/second,
> showing 100% load on one core.  Newer CPUs with greater single core
> performance are sure to provide even higher results.
>
>
> -----Original Message-----
> From: radiator-bounces at open.com.au
[mailto:radiator-bounces at open.com.au 
> ]
> On Behalf Of Patrick, Robert
> Sent: Friday, May 15, 2009 8:39 PM
> To: radiator at open.com.au
> Subject: Re: [RADIATOR] Load testing radiator
>
> Matthew,
>
> Running a quick test here with no real tweaking supports 2100~2200
> requests/second on a server running Radiator 4.4 with latest patches.
>
> Server has four cores total (two Dual Core AMD Opteron(tm) Processor  
> 275
> 2.2Ghz processors).  Radiator runs at 100% on one of the four cores
> while servicing RADIUS requests from three physical desktop clients
> (each a 3Ghz Pentium-4) running two concurrent instances of radpwtst,
> for a total of six logical clients.  Server had a relatively simple
> Radiator configuration providing authentication from a text file.
> Increasing the number of logical clients to twelve (four instances of
> radpwtst per PC) produced the same results.
>
> radpwtst -noacct -auth_port 1812 -s 1.2.3.4 -secret 'secret' \
> -user guest -password qwerty -iterations 9999 > /dev/null &
>
> -----Original Message-----
> From: radiator-bounces at open.com.au
[mailto:radiator-bounces at open.com.au 
> ]
> On Behalf Of Hugh Irvine
> Sent: Wednesday, May 13, 2009 7:33 PM
> To: Matthew Watson
> Cc: radiator at open.com.au
> Subject: Re: [RADIATOR] Load testing radiator
>
>
> Hello Matthew -
>
> We generally use radpwtst.
>
> You should run radiusd with "-trace -1" so you can see the number of
> requests per second.
>
> 	perl radiusd -foreground -log_stdout -trace -1 -config_file
> your_configuration_file
>
> 	.....
>
> Then you should run radpwtst on a different host and note the number
> of requests per second, then run two instances of radpwtst and repeat.
>
> At  3 or 4 instances of radpwtst on a single host you should see the
> number of requests per second plateau.
>
> Then you should do the same thing on a second radpwtst host, etc.
>
> At some point you should see the number of requests per second plateau
> which will indicate how many requests radiusd itself can handle.
>
> We are available on a contract basis to assist with design and
> implementation of these types of systems.
>
> regards
>
> Hugh
>
>
> On 14 May 2009, at 09:21, Matthew Watson wrote:
>
>> Hi,
>>
>> I'm currently working on a new radius configuration and need to
>> test what load it can handle. Is there any scripts which come with
>> radiator which can assist with this or do people generally just
>> build their own using radpwtst or similar?
>>
>> Regards,
>> Matthew Watson
>>
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they
>> are addressed. Please notify the sender immediately by email if you
>> have received this email by mistake and delete this email from your
>> system. Please note that any views or opinions presented in this
>> email are solely those of the author and do not necessarily
>> represent those of the organisation. Finally, the recipient should
>> check this email and any attachments for the presence of viruses.
>> The organisation accepts no liability for any damage caused by any
>> virus transmitted by this email.
>>
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>
>
>
> NB:
>
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive
> (www.open.com.au/archives/radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
> Have you checked the RadiusExpert wiki:
> http://www.open.com.au/wiki/index.php/Main_Page
>
> -- 
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> Includes support for reliable RADIUS transport (RadSec),
> and DIAMETER translation agent.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
>
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator

NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive
(www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.