(RADIATOR) Threading support (again)

[Hugh Irvine]

Hello Robert -

The simplest way to do what you describe below is to have 31  
accounting tables, called ACCOUNTING_01, ACCOUNTING_02, etc., then  
set up your AuthBy SQL like this:


<AuthBy SQL>
	Identifier SQLAccounting
	DBSource .....
	DBUsername .....
	DBAuth ......

	AccountingTable ACCOUNTING_%d

	......
</AuthBy>


See section 5.29.8 in the Radiator 3.17.1 reference manual ("doc/ 
ref.html").

regards

Hugh


On 5 Sep 2007, at 21:24, Robert Blayzor wrote:

> Martin Wallner wrote:
>> Same problems here (peaks and so on)... where I'm not thinking that -
>> with current hardware - the problem does not lie in the amount of
>> requests and records that are sent to RADIATOR, the problem lies  
>> in the
>> authentication and accounting backbone of the system.
>>
>> Accounting inserts sometimes (and especially with excessive need of
>> re-writing the indicies) are a terrible strain on the DB, which then
>> goes back to Radiator, which is waiting for the ack to the db, that
>> sometime goes in to timeout, and so on.
>
> [...]
>
>
> I think we've (for the most part) found ways around this in some
> regards.  First and foremost it Radiator itself doesn't need a ton of
> processing power, at least from what I've found.  Most of the time
> Radiator is waiting around for either SQL or NAS acks/naks, etc.
>
> What we've found now is that having at least two servers running 2-4
> instances of Radiator per box, separating the accounting and
> authentication processes is required.
>
> If you separate the authentication from the accounting, at least your
> accounting should always be ultra fast as requests are not being  
> blocked
> or held up by SQL inserts for accounting records.
>
> The other thing that is extremely important as far as a performance
> boost is making sure you use stored procedures on the SQL server
> whenever possible.  Whenever you call massive amounts of SQL that is
> common in nature (ie: large accounting insert statements), the
> pre-compiled and syntax checked SQL is a massive performance boost.
>
> The other thing we've found is that keeping indexes OFF on the SQL
> accounting table where records are directly injected.  By doing this,
> accounting record inserts are typically almost as fast as SELECT's
> because each and every record doesn't need to be index processed.  If
> you do that on a daily basis, you can then have a procedure to take  
> the
> records from the daily table and move them into an index based master
> table.... then just remove the old records from the daily table once
> they are moved.  Depending on how large your daily table actually  
> grows,
> you may want to create a procedure that creates the new daily table,
> renames the last one, renames the new one and deal with the deletes
> later.  Depending on the # of rows you're deleting without indexes  
> could
> cause some insert blocking...
>
> HTH
>
> -- 
> Robert Blayzor
> INOC
> rblayzor at inoc.net
> http://www.inoc.net/~rblayzor/
>
> YOUR PC's broken and I'VE got a problem?
>  -- The BOFH Slogan
>
> --
> 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 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.


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