[RADIATOR] coping with a slow database server

[Patrick, Robert]

David - you may also want to try using a second database, faster than
the main, and write your accounting info to that database.  Then with a
different process, update the main (slow) database.  If your slow
database is a bottleneck, use a fast database as a buffer for the
information flow.  This also gives you the ability to summarize the
accounting info, potentially reducing the total number of records that
need to be inserted into the slow database.


-----Original Message-----
From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au]
On Behalf Of Hugh Irvine
Sent: Friday, June 26, 2009 6:19 AM
To: David J Craigon
Cc: radiator at open.com.au
Subject: Re: [RADIATOR] coping with a slow database server


Hello David -

As mentioned, you should add "AccountingHandled" to your Realm(s) or  
Handler(s).

This will cause Radiator to send an accounting response immediately.

You can also try the "FarmSize n" parameter in Radiator 4.4.

regards

Hugh


On 26 Jun 2009, at 20:13, David J Craigon wrote:

> Hi Hugh,
>
> Yeah, we're already doing this. This server doing accounting packets
> only. The problem in a bit more detail is:
>
> My dodgy routers have lots of subscribers- they are LNSs.. They try
> and send accounting packets periodically for all their subscribers.
> They can only handle 30 RADIUS connections at once. A connection
> counts from when they send the accounting request until when they get
> accounting accept.
>
> Because my radiator is attached to a s-l-o-w database server, radiator
> can sometimes take a long time between radius accounting packets
> arriving and the accept being sent. Because the router has lots more
> radius accounting it wants to send (because it's got a lot of
> customers on them), it goes to 100% CPU and things go bad.
>
> What I'm looking for is some way Radiator can accept the traffic, then
> work out doing the write to the database later.
>
> So in conculsion the routers do bad things, the database server does
> bad things, and Radiator is fine. Naturally therefore I want to fix
> Radiator ;-).
>
> David
>
> 2009/6/23 Hugh Irvine <hugh at open.com.au>:
>>
>> Hello David -
>>
>> You can use "AccountingHandled" in your Realm or Handler.
>>
>> See section 5.17.10 in the Radiator 4.4 reference manual ("doc/ 
>> ref.pdf").
>>
>> You can also try the new "FarmSize n" parameter in Radiator 4.4.
>>
>> See section 5.4.39 in the manual.
>>
>> You can also run two instances of Radiator, one for authentication  
>> and the
>> other for accounting.
>>
>> regards
>>
>> Hugh
>>
>>
>> On 22 Jun 2009, at 23:42, David J Craigon wrote:
>>
>>> Hello,
>>>
>>> I run Radiator as an accounting server. I use AuthBySQL and an
>>> AcctSQLStatement. I am suffering with my database server being slow
>>> and hopeless, which in the short term I can't do anything about.
>>>
>>> Now, as a understand it the order of packets from my router is...
>>>
>>> Radiator receives accounting request
>>> Radiator writes to database
>>> Radiator send accounting accept.
>>>
>>> If the database query is slow, we suffer from the accounting accept
>>> taking a long time. This upsets my routers.
>>>
>>> Is there any way I can do:
>>>
>>> Radiator receives accounting request
>>> Radiator send accounting accept.
>>> Radiator writes to database later
>>>
>>> I've seen a few mailing list posts about this in the past, but  
>>> nothing
>>> that seems to do what I want.
>>>
>>> David
>>> _______________________________________________
>>> 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?
>> Have you checked the RadiusExpert wiki:
>> http://www.open.com.au/wiki/index.php/Main_Page
>>
>> --
>> 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.
>>
>>
>>



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?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

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


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