(RADIATOR) Radiator & Server Capacity

Hugh Irvine hugh at open.com.au
Mon Feb 14 23:54:41 CST 2005


Hello Ash -

Many thanks for your coments - most interesting.

regards

Hugh


On 15 Feb 2005, at 02:43, Ash Garg wrote:

> Guys,
>
> I configured up radiator to talk to a SQLdb, permanently set the trace 
> level
> to 4 and spit the output to log files. I then use a perl script to 
> parse the
> logfiles and graph this with mrtg and found this gives me more 
> realistic
> values compared to trace -1. I use a similar technique to measure the
> min/max/avg response times.
>
> For the generator, I use a Spirent Ax4000 with a specially written 
> script
> that crafts around 17000 unique access requests and fires them at a 
> chosen
> rate (1pps to 150pps).
>
> Attached is a mrtg graph which shows some results of my testing in 
> week 2
> and 3. I didn't know about "LogMicroseconds" and will have to give 
> that test
> in the lab.
>
> Regards,
> Ash
>
>
>
>
>
>
>
>                                            \\\|||///
>                                           \\  ^ ^  //
>                                            (  6 6  )
> -----------------------------------------oOOo-(_)-oOOo---
> Ash Garg                             5/490 Northbourne Ave
> Network Specialist                   DICKSON 2602
> Internet Network Development
> Telstra
>
> Email: <<mailto:Ash.Garg at telstra.net>>
> BH:  +612 6208 1994
> Mob: 0408 687 642
> Fax: +612 6248 6165
>
>
> This communication may contain CONFIDENTIAL or copyright
> information of Telstra Corporation Limited (ABN 33 051 775 556).
> If you are not an intended recipient, you MUST NOT keep,
> forward, copy, use, save or rely on this communication, and
> any such action is unauthorised and prohibited. If you have
> received this communication in error, please reply to this e-mail
> to notify the sender of its incorrect delivery, and then delete
> both it and your reply. Thank you.
>
> ----------------------------------------------------------
>
>
> -----Original Message-----
> From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au]On
> Behalf Of Hugh Irvine
> Sent: Monday, 14 February 2005 5:18 PM
> To: S H A N
> Cc: Radiator
> Subject: Re: (RADIATOR) Radiator & Server Capacity
>
>
>
> Hello Shan -
>
> What we do here is the following:
>
> start Radiator like this:
>
> 	perl radiusd -foreground -log_stdout -trace -1 -config_file ......
>
> the "-trace -1" will cause Radiator to log the number of requests
> processed per second to the command line, once per second
>
> then on another host, run the radpwtst program in a script to do random
> username/password checks
>
> check the number of requests per second processed by radiusd
>
> repeat running the radpwtst script with multiple instances until the
> number of requests per second shown by radiusd stabilises
>
> then move to another host and run the same radpwtst scripts again until
> the number of requests per second shown by radiusd stops increasing
>
> repeat the above step as many times as neccessary
>
> this will show you the maximum number of requests per second that this
> instance of radiusd can process
>
> it is usually a good idea to start with a very simple instance of
> radiusd with just an AuthBy INTERNAL clause to establish a baseline
>
> Note that it is essential to run the radpwtst scripts on separate hosts
> so that there is no interference with the radiusd process. Also note
> that it is essential to do "random" username/password checks to avoid
> cache hits giving misleading statistics.
>
> You can of course also use any of the radius stress testing tools to
> accomplish the same thing.
>
> Once you have the performance numbers, you should run radiusd with
> -trace 4 and a LogMicroseconds logger so you can see exactly how much
> time the various processing steps are taking. Our observations are that
> it is almost always external resources like SQL or LDAP databases that
> limit performance. In almost all cases a good database administrator is
> your best friend!
>
> Hope that helps.
>
> regards
>
> Hugh
>
>
>
> On 14 Feb 2005, at 06:17, S H A N wrote:
>
>> hi,
>> 	is there are recommended approach on how to define
>> radiator/server capacities?
>>
>> 	how can i find out that what would it take from radiator (radius
>> traffic and no. of instances) to saturate the computing resources.
>>
>> rgds,
>> --
>>
>> --
>> Archive at http://www.open.com.au/archives/radiator/
>> Announcements on radiator-announce at open.com.au
>> To unsubscribe, email 'majordomo at open.com.au' with
>> 'unsubscribe radiator' in the body of the message.
>>
>>
>
> 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?
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> -
> 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.
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
> <lon-radius-month[1].png>

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?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
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.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list