(RADIATOR) threading

[Andrew]

I realise this works well because AuthRADIUS can be configured not to
block as other modules do. As I mentioned before, I don't intend on
solving this problem by load-balancing, but rather by doing the Right
Thing and removing the bottleneck so that a single thread can cope with
the load. It just led me to ask the question.

Andrew


On Fri, 22 Oct 2004, Hugh Irvine wrote:

>
> Hello Andrew -
>
> Note that on a single host you can also set up a "front-end" radiusd
> process listening on the port that your NAS's are sending to, and
> configure it with an "AuthBy LOADBALANCE" clause configured to send to
> some number of "back-end" radiusd processes each listening on a
> different port.
>
> In other words have all of the load balancing happening on the one host
> and configure whatever number of "back-end" processes work best.
>
> This is a simple and effective way of implementing what you describe
> with the existing Radiator modules.
>
> regards
>
> Hugh
>
>
> On 22 Oct 2004, at 14:26, Andrew wrote:
>
> >
> > 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.
> >>
> >>
> >
> >
>
> 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.