(RADIATOR) threading

[Hugh Irvine]

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.