(RADIATOR) Radiator & Server Capacity

Mon Feb 14 17:43:14 CST 2005

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lon-radius-month[1].png
Type: image/png
Size: 2197 bytes
Desc: not available
URL: <http://www.open.com.au/pipermail/radiator/attachments/20050215/9e43a8c1/attachment.png>