AW: (RADIATOR) radiator performance benchmarks?

Tue Mar 23 04:10:31 CST 2004

Perhaps everyone can agree that Radiator is a queue/flow processor,
methods to enable parallel processing involve forking, threading and 
multiple instances and there are pros and cons to each. Perhaps these 
pros and cons with respect to backends and processing can be listed 
on the Radiator site?

Rgds,
-GSH

----- Original Message ----- 
From: "Hugh Irvine" <hugh at open.com.au>
To: "Huber, Rainer" <rainer.huber at gmx.at>
Cc: <radiator at open.com.au>
Sent: Monday, March 22, 2004 10:40 PM
Subject: Re: AW: (RADIATOR) radiator performance benchmarks?

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

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