(RADIATOR) Threading support (again)

[Robert Blayzor]

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.

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