(RADIATOR) threading

[Hugh Irvine]

Hello Andrew -

This topic comes up from time to time (see the mailing list archive).

Our standard response is that Perl does not currently support 
"production-quality" multi-threading, nor do many modules. This being 
the case we tend to recommend that people use a load-balancer (either 
hardware or one of the Radiator modules) and multiple instances of 
radiusd on multiple hosts. In addition we suggest a very simple 
approach of simply running an authentication instance and an accounting 
instance on each Radiator host.

We have talked about a pool of children and so forth, but have decided 
that the effort is too great given the simple alternatives.

Note that threading in and of itself is also not necessarily going to 
improve anything and indeed may just lead to an exhaustion of system 
resources.

In almost all cases that we have been asked to look at the fundamental 
problem has been a "slow" database backend, and fixing the backend has 
fixed all the problems.

regards

Hugh


On 22 Oct 2004, at 11:42, Andrew wrote:

>
> Hi,
>
> I'm experiencing a performance bottleneck in Radiator due to "slow"
> requests of the type that Fork is recommended for. They aren't really 
> that
> slow at about 200ms, but the bottom line is they are coming in faster 
> than
> they can be read from the socket. The 200ms is due to network latency, 
> not
> load on the Radiator host itself.
>
> I didn't expect Fork to work well, but tried it anyway. Forking on each
> and every request made that 200ms into 800ms (and wreaked havoc with 
> DBI).
> It led me to wonder though if Radiator could support a predefined pool 
> of
> children. If I had a way of running two Radiator processes receiving
> requests to a shared IP/port (I don't have a load balancer available),
> then my problem would be solved. It would also scale quite well, I'm 
> sure
> I could run 10 without load issues, providing they are preforked. Is 
> this
> practical in anyway?
>
> I'm aware the obvious solution is to remove the latent network 
> component.
> I'm also aware that another Radiator host could do the load balancing 
> for
> me. I'm really just curious as to whether Hugh and Mike have any plans 
> for
> anything like this.
>
>
> Regards,
> Andrew
>
> --
> 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 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.