(RADIATOR) Threading support (again)

[Hugh Irvine]

Hello Alexander -

Can you clarify what you mean by "snmp checks"?

regards

Hugh


On 3 Sep 2007, at 23:54, Hartmaier Alexander wrote:

> Hi!
>
> We encountered similar problems in the last few month when traffic  
> rises.
> Have you thought about using POE and various components (like  
> asynchronous DBI
> calls) for Radiator?
> For us it seems that the accounting inserts block radiator sometimes.
> How could be snmp checks be logged to verify that aren't the cause  
> of our
> problems?
> I never saw a single log line for those even with a trace 5 log.
>
> With best regards
> Alexander Hartmaier
>
> T-Systems Austria GesmbH
> Rennweg 97-99
> A-1030 Vienna
>
> phone: +43-(0)57057-4320
> mobile: +43-(0)676-8642-4320
> -----Original Message-----
> From: owner-radiator at open.com.au [mailto:owner- 
> radiator at open.com.au] On Behalf
> Of John Morrissey
> Sent: Friday, August 24, 2007 11:46 PM
> To: radiator at open.com.au
> Subject: (RADIATOR) Threading support (again)
>
> Looking through the archives, it's been a long time since someone's  
> kicked
> the threading horse.
>
> We've been running Radiator on a fairly substantial RADIUS  
> installation (a
> dozen or so machines in three locations across the United States) for
> several years now, making use of an LDAP directory for account  
> storage.
> (Hugh or Mike, feel free to e-mail me privately if you need more
> information.) Unfortunately, OpenLDAP libraries do not seem well  
> behaved
> when Radiator forks, although it's been a while since we've tried.
>
> Our largest problem with a monolithic process is that we've had  
> occasional
> problems where device outages cause thousands of subscribers to
> reauthenticate simultaneously. This overwhelms our authentication  
> radiusd
> instances, causing UDP network queues on that port to skyrocket,  
> eventually
> leading to a cascade failure that is obnoxious to recover from, to  
> say the
> least. Our RADIUS servers are by no means underpowered, but it's  
> just not
> cost-effective to maintain a huge (and otherwise idle) hardware  
> pool just to
> handle occasional huge spikes like this.
>
> Additionally, we're starting to deploy machines with four CPU cores  
> as their
> price has dropped substantially. We like sticking to a fairly standard
> configuration, so we'd like to avoid "wasting" hardware that  
> Radiator will
> never use (we have auth and accounting split into two Radiator  
> instances).
> We could run more radiusd processes on different ports or IP  
> addresses, but
> this seems wasteful and complex.
>
> Lastly, we're looking at implementing simultaneous use restrictions  
> and are
> concerned that the state refresh (SNMP in some cases, locally  
> implemented
> interfaces to proprietary devices in others) will block radiusd  
> excessively.
> We're also looking at proxying to more customers, and are concerned  
> that
> unreachable or underperforming proxy destinations will cause the same
> behavior.
>
> We had considered implementing rate limiting to handle our first  
> concern
> above, but that doesn't get us anywhere with the others. To that  
> end, I'm
> toying with the idea of adding a new process model to Radiator  
> somewhat akin
> to Apache's prefork MPM, with a number of child processes (not  
> threads)
> running round-robin on the incoming UDP port or handling work  
> directed at
> them via some sort of IPC from a central request handler process.
>
> I haven't dived into the code yet to see how non-trivial this will  
> be, and I
> thought I'd ask around here first to see what everyone's thoughts  
> are. I
> know that a threaded model hasn't been implemented due to alpha- 
> quality
> thread support in Perl, and I haven't looked into its current state  
> yet.
> That's part of the reason I'm keen on using separate worker processes
> instead of threads.
>
> thanks,
> john
> -- 
> John Morrissey          _o            /\         ----  __o
> jwm at horde.net        _-< \_          /  \       ----  <  \,
> www.horde.net/    __(_)/_(_)________/    \_______(_) /_(_)__
>
> --
> 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.