Re: (RADIATOR) Input queue size

[Hugh Irvine]

Hello Matthew -

You are quite correct. Radiator does an "open-write-close" for every 
log event.

In spite of this however I would not recommend having more than one 
Radiator instance writing to a log file as it becomes almost impossible 
to then understand what is going on. It is _much_ better to set up your 
logging using GlobalVar's passed in on the startup command line. This 
way you can have the same configuration file but have different 
instances logging to different files.

regards

Hugh

On 14/11/2003, at 3:51 AM, Matthew Trout wrote:

All radiator log accesses e done lock-write-unlock, IIRC, so you 
should be
fine.

I'd suggest double-checking with either the docs, the source, or Hugh 
before
putting it on a production system :)

-----Original Message-----
From: Vangelis Kyriakakis [mailto:[EMAIL PROTECTED]
Sent: 13 November 2003 08:59
Cc: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Input queue size
Can all these Radiator instances use the same logfiles? Or
they'll have
problems racing for file locks?
          Vangelis

Frank Danielson wrote:

It's really not that hard. You run a number of Radiator
instances, with each
one having it's own connection to the LDAP, SQL, or whatever
backend. Then
you front end those with an instance or two of Radiator
running AuthBy
ROUNDROBIN or AuthBy LOADBALANCE to distribute the requests
among them.
You can process quite a lot of requests simultaneously this
way. If your
current server is not responding fast enough but the CPU
utilization is not
maxed out you are probably just hitting the ceiling on how
many requests a
single instance can process at a time. Start up some more
processes on the
box and use all those processor cycles that you paid for.

-Frank

-----Original Message-----
From: Claudio Lapidus [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 9:19 PM
To: Gu�bj�rn S. Hreinsson; [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Input queue size
......

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.




===
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.
===
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.

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 [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.