(RADIATOR) radiator performance benchmarks?

[Tariq Rashid]

thank you for this informative response. 

i expect to start designing my tests within a month and will be in touch
here again for comments - i realise benchmarking is difficult ot make
menaingful! of course i'll also give the results here too!

tariq



-----Original Message-----
From: Huber, Rainer [mailto:rainer.huber at gmx.at]
Sent: 22 March 2004 21:38
To: radiator at open.com.au
Subject: AW: (RADIATOR) radiator performance benchmarks?


Hallo!

Forking in general was is real option for me because:
*) due to the fact that the number of forked child processes cannot be
   limited the machine would be unuseable in the case of problems with
the 
   backend(s). (I have many backend transactions in the flow)
*) The processes take ~50M of memory in my case => if the machine starts
   swapping under high load I guess the performance would break down.
(  *) we had pretty slow machines in the beginning   ;-)   )

But I would say that there is a good alternative to forking:

I have proxy frontends which balance incoming requests to many backend
radiators which are running on the same (or different) machine(s) (so
this equals to a "preforked server")
One proxy instance for authentication, one for accounting and >4 backend
instances behind each proxy per physical machine perform well for me.
The backends are started from the same config files (acct/auth) with
different log files and ports. 

So from my point of view there are the following advantages:
+) single threaded logfiles
+) limited memory consumtion
+) dramatically performance increase
+) scaleable to x instances (limit is CPU/RAM)
+) no fork with sql/ldap/library problems

I think you should also mention this scenario for your performance
tests.

regards,
Rainer



-----Original Message-----
From: Tariq Rashid [mailto:tariq.rashid at uk.easynet.net]
Sent: 22 March 2004 15:37
To: radiator at open.com.au
Subject: (RADIATOR) radiator performance benchmarks?



I know that Radiator is written in perl and it is single-threaded.
Despite
this, we have no problem running it in a pretty large scale deployment. 

However, we would like to be able to compare its performance with other
radius servers (in particular freeradius) - simply for capacity
planning.
When will we expect to add a new server to the load-balanced cluster? At
what requests/sec can we expect it to fail? What affect does accountign
have
on the server?

And even a set of benchmarks quantifying performance over a varying
underlying operating system. Perhaps linux 2.4/6, freebsd 4/5, different
perl varsions, different kernel parameters (eg preallocated mbufs?)

I'd also like to raise a quite odd statement in the O-Reilly Radius book
by
Hassell, published only at the end of last year which suggests at the
end of
his book that Radiator is only for small setups. Surely not? He doesn't
say
why?

Tariq

--
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.
This email and any attachments may be confidential and the subject of
legal
professional privilege.  Any disclosure, use, storage or copying of this
email without the consent of the sender is strictly prohibited. Please
notify the sender immediately if you are not the intended recipient and
then
delete the email from your inbox and do not disclose the contents to
another
person, use, copy or store the information in any medium.

--
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.


--
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.

--
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.