(RADIATOR) Re: Performance Issue

[Hugh Irvine]

Hello Andrew -

You should add a Log FILE clause to your configuration file, with  
LogMicroseconds enabled (requires Time-Hires from CPAN).

This will show you exactly how long each processing step is taking in  
a trace 4 debug.

If you send me a copy of the debug I will take a look.

regards

Hugh




On 20 Feb 2006, at 16:03, Andrew Weighell wrote:

>
> Hi Guys,
>
> I am currently evaluating Radiator as a possible replacement for  
> our current solution. However, I have come across a small issue  
> relating to the performance of Radiator or perhaps Active Perl. I  
> am using a Radius test client (not radpwtst) to send just an Auth  
> request to a Radiator, this test client works fine with our current  
> solution so I don't believe the client could be causing the delay.
>
> Radiator has been setup on a Dual Xeon 3.4GHz with 2GB of RAM  
> (running Microsoft Windows Server 2003 Standard Edition),  
> connecting to a MSSQL DB. A profile running on our DB shows the  
> database is responding instantly with no apparent delays but  
> Radiator is averaging 150-200ms per request which is quite bad when  
> you are processing hundreds of requests a minute or more. Is there  
> any optimising of Active PERL or Radiator that can increase this  
> performance, to around say only 16ms or less per request??
>
> My config file is below:
>
> Foreground
> LogStdout
> LogDir		.
> DbDir		.
> Trace		1
>
> # You will probably want to change this to suit your site.
> <Client XXX.XX.XXX.X>
> 	Secret	mysecret
> </Client>
>
> # You can put client details in a database table
> # and get their details from there with something like this:
> <ClientListSQL>
> 	DBSource	dbi:ODBC:DBServer
> 	DBUsername	User
> 	DBAuth	test
>
> 	GetClientQuery select IPAddress, Secret from radius.dbo.servers
>
> 	# If RefreshPeriod is set to non-zero, it specifies the period in  
> seconds that the client list will
> 	# be refreshed by rereading the database. Each RefreshPeriod,
> 	# any Clients previously created by this ClientList are
> 	# cleared and a new set of clients read from the database.
> 	# Clients defined in the configuration file will not be clobbered.
> 	# The same effect can be got by signalling the process with with  
> SIGHUP
> 	#RefreshPeriod 600
> </ClientListSQL>
>
> # This will authenticate users from SUBSCRIBERS
> <Realm DEFAULT>
>      AuthByPolicy ContinueWhileReject
>     <AuthBy SQL>
> 	# Adjust DBSource, DBUsername, DBAuth to suit your DB
>
> 	DBSource	dbi:ODBC:DBServer
> 	DBUsername	User
> 	DBAuth	test
>
> 	NoDefault
>
> 	AuthSelect EXEC AuthCustomer '%{User-Name}','%{Radius-Attribute}',1
>
> 	AuthColumnDef 0, User-Password, check
> 	AuthColumnDef 1, GENERIC, check
> 	AuthColumnDef 2, GENERIC, reply
>
> 	AccountingTable CALLS
>
> 	AcctColumnDef NASIdentifier,NAS-IP-Address
> 	AcctColumnDef NASPort,NAS-Port,integer
> 	AcctColumnDef AcctSessionID,Acct-Session-Id
> 	AcctColumnDef AcctStatusType,Acct-Status-Type
> 	AcctColumnDef CallDate,Timestamp,integer
> 	AcctColumnDef UserName,User-Name
> 	AcctColumnDef AcctDelayTime,Acct-Delay-Time,integer
> 	AcctColumnDef AcctSessionTime,Acct-Session-Time,integer
> 	AcctColumnDef FramedAddress,Framed-IP-Address
> 	AcctColumnDef AcctInputOctets,Acct-Input-Octets,integer
> 	AcctColumnDef AcctOutputOctets,Acct-Output-Octets,integer
> 	AcctColumnDef CallerID,Calling-Station-Id
>
>     </AuthBy>
>     <AuthBy SQL>
> 	# Adjust DBSource, DBUsername, DBAuth to suit your DB
>
> 	DBSource	dbi:ODBC:DBServer
> 	DBUsername	User
> 	DBAuth	test
>
> 	NoDefault
> 	NoCheckPassword
>
> 	AuthSelect EXEC AuthCustomer '%{User-Name}','%{Radius-Attribute}',2
>
> 	AuthColumnDef 0, User-Password, check
> 	AuthColumnDef 1, GENERIC, reply
>
> 	AccountingTable CALLS
>
> 	AcctColumnDef NASIdentifier,NAS-IP-Address
> 	AcctColumnDef NASPort,NAS-Port,integer
> 	AcctColumnDef AcctSessionID,Acct-Session-Id
> 	AcctColumnDef AcctStatusType,Acct-Status-Type
> 	AcctColumnDef CallDate,Timestamp,integer
> 	AcctColumnDef UserName,User-Name
> 	AcctColumnDef AcctDelayTime,Acct-Delay-Time,integer
> 	AcctColumnDef AcctSessionTime,Acct-Session-Time,integer
> 	AcctColumnDef FramedAddress,Framed-IP-Address
> 	AcctColumnDef AcctInputOctets,Acct-Input-Octets,integer
> 	AcctColumnDef AcctOutputOctets,Acct-Output-Octets,integer
> 	AcctColumnDef CallerID,Calling-Station-Id
>
>     </AuthBy>
> </Realm>
>
>
> Any help on this would be greatly appreciated.
>
>
> Regards,
> Andrew
> ____________________________________
>
> Andrew Weighell
> Database Administration Team
> www.westnet.com.au
> Westnet - Voted Number 1 ISP in Customer Satisfaction two years  
> running
>
> Phone: (08) 6263 6300    Fax: (08) 6263 6366
> For more contact information visit our contact us webpage.
>

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