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

[Tariq Rashid]

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.