AW: (RADIATOR) radiator performance benchmarks?

Hugh Irvine hugh at open.com.au
Mon Mar 22 16:40:14 CST 2004


Hello Rainer, Hello Everyone -

This topic comes up on the mailing list periodically and Rainer's 
points below (thanks for the clear and concise observations) are 
exactly the same as my responses to the same questions.

Forking and multi-threading _may_ be useful in certain very specific 
cases, but in general are to be avoided. As Rainer correctly points out 
it is usually the case that using load-balancing and seperate instances 
for authentication and accounting are much easier to set up and 
administer.

In my own experience it is almost always external resources that are 
responsible for performance limitations - SQL and LDAP databases 
especially.

The largest system that I have worked on uses this approach 
(load-balanced, multi-instance) for Radiator and runs against a _very_ 
fast Oracle backend server. This setup has been tested to handle 1200 
radius requests per second (including authentication, accounting and 
address allocation).

Another system that I have done a lot of work on also uses Oracle and 
makes extensive use of stored procedures to dramatically increase 
performance.

We used to include some rudimentary benchmarks in the manual, but we 
found that they were difficult to make general enough and specific 
enough to satisfy everyone and we were constantly getting the same 
questions as we still get - "how fast will _my_ configuration go?".

My only recommendation to everyone is that the best answer will lie in 
your own testing of your own systems.

Also note that having a really good database administrator available is 
a major advantage.

BTW - in response to Tariq's comment below about the Radius book from 
O'Reilly - we were quite disappointed with the book (but of course we 
are biased).

regards

Hugh



On 23 Mar 2004, at 08:37, Huber, Rainer wrote:

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

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.


More information about the radiator mailing list