[RADIATOR] Radiator performance problem with specific hardware

[Leigh Porter]

When we built our platform here originally a few years back, we had
multiple instances with a Alteon load balancer. The back end to RADIUS
was LDAP again multiple instances with load balancers.

We gave up testing when we got to 10k requests a second..

That was with 2.8Ghx Xeons and two instances of Radiator and two
OpenLDAP.

--
Leigh



-----Original Message-----
From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au]
On Behalf Of Kukas Damjan
Sent: 02 September 2010 15:17
To: Hugh Irvine; Christian Kratzer
Cc: radiator at open.com.au list
Subject: Re: [RADIATOR] Radiator performance problem with specific
hardware

Hello guys,

Thank you for your responses. 

When we got to this problem, first thing what we did is to make test
with two instances of Radiator in the backend, each having 64 workers.
This kind of a setup got us the best results(around 8400
requests/second), like those we were hoping to get in the first place
with one Radiator instance with 128 workers.

The reason why we are trying to figure out where exactly the problem is
because it is much easier to have one instance of Radiator for
configuring and for handling the logs. There is of course possibility to
write all to one log, but solution with one instance if still preferable
solution.

If everything else fails, I believe we will go through with 2 or more
instances setup. 

@Christian: you mentioned lock contention issue, do you perhaps know
what will be best forum, or mailing list to ask around if this can be
fixed through Solaris configuration?

Regards

Damjan



-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au] 
Sent: Wednesday, September 01, 2010 3:31 PM
To: Kukas Damjan; Christian Kratzer
Cc: radiator at open.com.au list
Subject: Re: [RADIATOR] Radiator performance problem with specific
hardware


Hello Kukas, Hello Christian -

I agree with Christian - in my consulting practice I almost always find
that it is preferable to set up frontend / multiple backend instances of
Radiator designed to break up processing into separate processes running
on different ports.

At the very least you should be running separate instances for
authentication and accounting.

regards

Hugh


On 1 Sep 2010, at 08:20, Christian Kratzer wrote:

> Hi,
> 
> On Wed, 1 Sep 2010, Kukas Damjan wrote:
> 
>> Hello,
>> 
>> We are having problems with Radiator performance while using specific
hardware and software.
>> The hardware we're using is:
>> CPU: Sun SPARC T5140 - having 2 x SunSparc 1.2Ghz CPU, each CPU
having 8 cores, and each core simulates 8 virtual processors, so system
has 128 virtual (logical) processors
>> 
>> The software we're using:
>> OS: Solaris 10
>> Radiator 4.5.1.
>> 
>> The performance problem appears when using more than 64 workers
defined in FarmSize parameter. If we use more than 64 workers, number of
requests per second drops drastically (measured values: with 64 workers-
5400 requests/second, 128 workers - 1200 requests/second). By doing some
specific tests we've come to conclusion that problem
>> lies somewhere in simultaneous multiple read/write to socket (UDP
queue) mechanism.
> 
> from your description this does sound a lot like your are hitting a
lock contention
> issue in the operating system ( solaris ).
> 
> If you have enough Requests to saturate that many cores you might try
splitting the
> radiator into for example 4 instances on separate ports with each
instance having a
> farm of 32 workers.
> 
> That would give you 4 separate udp queues to 4 separate farms and
might
> perhaps get you around your operating system issue.
> 
> Of course you would have to distribute the load to the 4 instances
> either directly from your radius clients or via other means. I do not
know 
> if this is an option in your situation.
> 
> Greetings
> Christian Kratzer
> CK Software GmbH
> 
> -- 
> Christian Kratzer                      CK Software GmbH
> Email:   ck at cksoft.de                  Schwarzwaldstr. 31
> Phone:   +49 7452 889 135              D-71131 Jettingen
> Fax:     +49 7452 889 136              HRB 245288, Amtsgericht
Stuttgart
> Web:     http://www.cksoft.de/         Geschaeftsfuehrer: Christian
Kratzer
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



NB: 

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive
(www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
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.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
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.




The information contained in this e-mail message is privileged and
confidential and is for the exclusive use of the addressee. The person
who receives this message and who is not the addressee, one of his
employees or an agent entitled to hand it over to the addressee, is
informed that he may not use, disclose or reproduce the contents
thereof, and is kindly asked to notify the sender and delete the e-mail
immediately.


_______________________________________________
radiator mailing list
radiator at open.com.au
http://www.open.com.au/mailman/listinfo/radiator