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? >From my own corner, I wish it were possible to have more than one established connection with the SQL backend, so as to paralellize requests to a certain degree. But yes, I suppose that means multithreading, and AFAIK that's not possible under perl 5.6 nor 5.8 I think. Perhaps Perl 6 would do it? === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
