(RADIATOR) Performance and Tuning.

[Julio Cesar Pinto]

Hugh,

Thanks for your comments, our architecture is the following:

1 Foundry Load Balance
2 FrontEnd Server (Dual Intel Xeon 2.4GHz with 1GB in ram)
	Each Server have running 2 radiator process (auth/acct), maybe I
take 	the recommendation of Dave to split the auth/acct process.
1 Sun RS 480 with 1GB in RAM (As a Oracle server with 9i version)

The Sun is connected with the foundry through GigaEthernet interface,
and don't have errors or collisions. 

We did a time ago a tunneling into the DB, verify indexes etc, etc,
additionally with tnsping we never lost request. 

I other words I think that we have a stronger architecture, so, our idea
is try to use the better configuration to us.

Can I use LogMicroseconds with Log SQL, or just with Log File?

I appreciate any comments that can help us to improve our system.

Thanks in advance,

JC.

-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au] 
Sent: Thursday, September 09, 2004 9:17 PM
To: Julio Cesar Pinto
Cc: radiator at open.com.au
Subject: Re: (RADIATOR) Performance and Tuning.


Hello Julio -

The only way to verify what is going on is to set up Radiator with a 
LogMicroseconds logger (requires Time-HiRes from CPAN) and check the 
time that is being taken for the various processing steps.

A Radiator configuration with 350 Handler clauses is not going to 
perform terribly well and you can probably optimise your database as 
well.

In almost all cases that I have looked at the bottleneck is the 
database, so you should check a trace 4 debug from Radiator as 
described above together with the performance and tuning data from your 
database.

BTW - the largest operation that we are familiar with uses 6 frontend 
Radiator hosts that are load balanced, operating against a very fast 
Oracle backend server. This setup has been tested to 1200 radius 
requests per second.

regards

Hugh


On 10 Sep 2004, at 08:59, Julio Cesar Pinto wrote:

> Hi,
>
> I want to know what is the max load that radiator could support.
>
> At the moment I have aprox 200 session current, and our configuration
> have aprox 350 Handler clauses, at the moment we have in some nases
the
> error radius client timeout, we are sure that we don't have problems
> with networking because we don't lose packets icmp in the same moment
> that we receive a timeout.
> We store all accounting packets in an oracle database.
>
> So, my question is, we are reaching the capacity of radiator.
>
> Please let me know.
>
> Thanks in advance,
>
> JC.
>
> --
> 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.