(RADIATOR) hmmm.. can't seem to stress the radiator radius server

[Hugh Irvine]

Hello Tariq -

I'm not quite sure what results you are looking at, but to see the 
number of requests per second that are being processed you should do 
this:

	perl radiusd -log_stdout -foreground -trace -1 -config_file ....

Running radiusd with -trace -1 will show you the number of requests per 
second, once per second.

perl radiusd -log_stdout -foreground -trace -1 -config_file simple.cfg
Fri Apr  9 10:20:15 2004: DEBUG: Reading users file ./users
Fri Apr  9 10:20:15 2004: DEBUG: Finished reading configuration file 
'simple.cfg'
Currently handling 0 requests/sec
Currently handling 0 requests/sec
Currently handling 0 requests/sec
......

You should run your radius clients on seperate hosts (not the same host 
as is running radiusd).

regards

Hugh


On 9 Apr 2004, at 01:17, Tariq Rashid wrote:

>
> i'm trying to stress the radiator radius server for benchmarking and 
> capacity
> planning purposes:
> 	* i tried fork()ed processes to throw lots of
> 	  queries at the server - the client overloaded with
> 	  too many forked processes by running out of memory
> 	* threads allowed much more concurrency, but the clients
> 	  are single CPU and so in reality there is no gain the
> 	  radius request rate
> 	* i used a very high powered 2-cpu (hyperthreaded too)
> 	  machine to send out requests (single-no-thread and 4 thread)
> 	  and even with no sleep() between each request
>
> and again - my results of the radius repsonce is almost always flat...
> with many threads/forks the flat graophs are hiogher (indicating client
> side delays if anything). but as the request rate increases, the 
> responce
> times don't appear to increase.
>
> i'm puzzled. any ideas?
>
> further to the above i tested 4 separate clients each belting out as 
> many request with no delays as they could. the repsonce rate was flat, 
> but as i enabled more clients, the radiator responce did go up to a 
> new flat ....
>
> so the conclusions i come to are that the radiator responce depends on 
> the number of different clients  - the puzzling results seem to show 
> that the request RATE doesn't seem to affect the reply speed.
>
> surely something worng somewhere? as anyone got similar experience in 
> this... is this a common fault?
>
> (some else explained that forks and threads don't increase radius 
> request performance - quite the opposite. only beneficial ase is when 
> the replies take a long time... but since radiator is a sequential 
> server... there is no benefit to concurrent clients).
>
> --
> 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 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.