(RADIATOR) threading

[Andrew]

Thanks Hugh,

I have a situation where Accounting alone can cause the problem, I'm
already running a seperate process.

I can understand Radiator not supporting ithreads.

My problem is definitely caused by network latency, but given our
requirements and resources it is difficult to remove. It'll almost
certainly involve compromises elsewhere in our systems, but I've accepted
it as our only option.

I'd still love to see this feature, as it can do half the job of an
expensive L4-7 load balancer. It's a shame to see Radiator get a buffer
overflow simply because there isn't mechanism to handle the requests with
two processes. Forking and threading with ithreads on every request is
probably not so scalable, but a tunable number of children on a powerful
system would make for a very powerful radius server, complementing a
load-balanced farm rather than replacing it.

Thanks for your reply, most appreciated.

Regards,
Andrew



On Fri, 22 Oct 2004, Hugh Irvine wrote:

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