(RADIATOR) Re: help with radiator problems

[Hugh Irvine]

Hello Laurens -

On Mon, 31 Dec 2001 11:52, Laurens Thissen wrote:
> Dear Open Systems consultants,
>
> I wasn't involved directly in the problem solving regarding our Radiator
> system at RDC Datacentrum, till now.
>
> Looking at the e-mail exchange from the last few days, I must conclude that
> your support is beneath my expectations.
>

I regret that you feel this way, as we always try to provide excellent 
support to everyone who uses Radiator.

I think you will find that I have spent a very great deal of time assisting 
RDC over the past several months, and I am happy to continue doing so.

> The total Radius system has been configured based on your specifications,
> also the indexing of the database, the OS, Radiator itself and Radmin.
>

As we are not on site it is quite difficult for us to see exactly what is 
happening on your system. I have made numerous suggestions including the 
latest one to do some trace 4 logging with the LogMicroseconds parameter so 
as to ascertain exactly where the time is being spent, and the results of 
those tests indicate that Radiator itself is responding very quickly, but the 
SQL queries to the database are taking an extremely long time (around one 
second per authentication).

You should look closely at the debug output that you sent to me to see which 
queries are taking the longest and then investigate those. The 6 digit number 
following the timestamp in the debug log indicates the number of microseconds 
that have elapsed (ie. the first digit of the six indicates tenths of a 
second).

> I really appreciate when you do the following:
> - good en sufficiant problem solving (and not only answers like "look at
> the database index, because it's slow", we came already to the same
> conclusion) 

I think the way forward is to do some performance measurements on your 
database to find out where the problem lies. There may or may not be a 
problem with the indexes, or there may be a problem with the database server 
process itself. I would suggest you check the tuning suggestions for your 
particular database and use whatever tools are provided with it to see 
exactly what is going on.

As mentioned previously, from what I can see in the trace 4 debug from 
Radiator, there does not appear to be a problem with Radiator itself.

> - when there are any recommendations to increase the
> stabilization of our Radiator system, please give them! In the next few
> days at the beginnen of the new year, our customers (growing to 16000 and
> now already 7000) will make many concurrent dial-up (up till 1000)
> connections, so we must have a stable Radius system! - when there are any
> points at your side not to be clear regarding our problem, please give us a
> call. At the 2nd of January we start at RDC with ultimate efford to
> implement a stable Radius (Radiator) system, I am convinced that you'll
> join us! So please mail us your advice or questions before the 2nd of
> January. May be it is good to make a conference call?
>

We have many customers with millions of customers in SQL databases and 
transaction rates of several hundred per second, so I am sure that your 
system will provide excellent service.

I am happy to participate in a conference call, providing we can arrange a 
suitable time. I am located in Melbourne Australia and we are approximately 
10 hours ahead of you, so your morning is my early evening.

regards

Hugh


-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
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.