Re: (RADIATOR) Very busy Radiator system.

[Carles Xavier Munyoz Bald�]

Hugh Irvine wrote:
> You can certainly try the "Fork" parameter if you wish, but keep in mind that
> it will duplicate the entire Perl+Radiator process for each packet that is
> processed by the AuthBy in question. We would be interested in the results of
> your experiments.

Hello again,
I have tried the fork parameter with the configuration:
<AuthBy DBFILE>
   Fork
   Filename        %D/userdb
</AuthBy>

But this doesn't solve the problems.
I have seen that after the Radiator has created its child process, it
uses the waitid system call and waits for its child to finish its
execution:
waitid(P_PID, 17340, 0xEFFFF8E8, WEXITED|WTRAPPED|WNOHANG)

This has the same effect than make the radius packet processing
sequential.
If the child process has problems to comunicate with the NAS (using
SNMP) or with the data base engine, Radiator will wait until it timeouts
and finish its execution, to continue processing the next radius
packets.
This wait, this time of inactivity, (may be lot of seconds) is the
important problem I have reported you in another e-mail.

I'm using Alteon devices to redirect the UDP radius traffic to varios
radius hosts, but this is not the solution. The problem is still here
with the redirectors configuration.

For example, imagin that I have my configuration with one Alteon and two
radius hosts. One of the NAS fails. 
If one Access-Request arrives to host radius 1 and makes that Radiator
use SNMP to query the failed NAS, this will make that the Radiator
server in host 1 doesn't process any more radius packet during 6 seconds
(the time required by the snmpget program to timeout).
The NAS will timeout (5 seconds) and retransmit the Access-Request. This
Access-Request will be send by the Alteon to the radius host 2 (radius
host 1 is not responding to the Alteon test) and the Radiator server in
this host will use SNMP to query the failed NAS. 
At this moment, my radius system is blocked and will not process any
more radius packets during some seconds.
If there are lot of SNMP queries over the failed NAS, the radius system
may be stoped during various seconds, making that NAS generates
retransmisions.

This problem may appear too if there are comunications problems with the
sessions data base engine, or this engine responds slow to the Radiator
SQL queries.

Do you have any idea about when will the multi-thread perl and Radiator
avaible ?
I really trust the Radiator radius server. It has gone very very fine
since now, but this perfomance and software design problem is making me
think in look for another radius server, because I see that Radiator
doesn't match my High Avaibility requeriments at 100%.

One personal question... Why decided you to program it in Perl and not
in C ?
With C the generated code will be more optimized and the wait problem
will have a very easy solution (multi-thread or fork).

Thanks for your help.
---
Carles Xavier Munyoz Bald� / [EMAIL PROTECTED]
Wanadoo Espa�a
Dpto. Sistemas / System Department
Tel: +34 96 5040000 Ext. 40046 - Fax: +34 96 5040047
http://www.wanadoo.es/
---

===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.