(RADIATOR) Radiator & Server Capacity

[Hugh Irvine]

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.