(RADIATOR) Input queue size

[Claudio Lapidus]

Hello Guðbjörn

> this may be unrelated, but I am interested to any and all tuning
> listmembers have done in the OS for Radiator performance. We
> are running two radiator servers with one proxy radiator in front
> and a seperate sql machine and ldap machine.

Fine, but what OS do you use? It might be interesting to have a hardware
summary too.

[snip]

> Lengthening the udp queues seems to really have adverse effects on
> this situation. We have not really tried shortening the queue which
> might really have even more adverse effects, without testing though
> I can't tell.

I can imagine that lengthening the queue only adds to the effect of the
server processing "old" packets, i.e. packets whose original timer (at the
NAS) has already expired. The root problem is the mismatch between the speed
of the NAS sending packets and the server processing them. Probably is worth
trying to increase the timeout setting at the NAS, at least to diminish
retransmissions (but beware of total authentication time then). A quicker
failover to a less loaded secondary might help too.

>
> To counter this we have configured multiple instances of radiators
> for authentication&authorization and accounting and instances for
> seperate NAS's or NAS groups. This in effect simulates having a
> threaded radiator to reduce the effect of this sequential processing.

OK, but are you sure that the bottleneck is in at the Radiator level or
might it be at the LDAP server? In the latter case it probably won't be of
much help anyway.

>
> This has not seemed to be related to CPU load or network performance,
> we have looked at these in detail.

No, it's probably more I/O bound, (disk, I mean).

> If anyone has input on this issue or OS tuning for Radiator I'd love
> to hear about it. Hope you understand my attempt to explain the above
> scenario. Basically we have a pretty stable environment today, but
> perhaps overly complex to manage because of the multiple instances.

Back to my original question then, I'm struggling to measure the effective
length of the input queue in Solaris. Linux's netstat shows it readily, and
I remember Tru64 doing the same. But Solaris' netstat lacks this one,
apparently. I'll have to continue my quest...


> Hugh, is a "threaded" ldap handler on the horizon? Is this perl or
> radiator related?