Hello Julio -
I think you will find that most of your problems are due to the testing
procedure that you are attempting to implement. There are two main problems
to start with. The first is your configuration file, using "Trace 4" - this
will slow Radiator down considerably - you should use "Trace -1" for testing.
The second problem is the way you are using radpwtst. Your test script is
starting 1000 copies of radpwtst, which is not the right approach - you
should use only three or four copies of radpwtst with the -iterations
parameter.
You should really start with a very simple setup:
- one machine running Radiator with just a simple AuthBy TEST config
(using Trace -1)
- a second machine with 3 or four copies of radpwtst
(start with one copy to set a base result, then add more)
Once you have some base results, then you can start to change the
configuration. You can for example run 2 instances of Radiator, one on the
auth port and the other on the acct port. When you have some results from
that, you can start to add things like MySQL and LDAP to see where the time
is being spent.
As mentioned however, running 1000 copies of radpwtst is not the correct
approach.
regards
Hugh
On Tuesday 06 February 2001 02:31, [EMAIL PROTECTED] wrote:
> yes Ingvar, you're right. First we put 10 seconds (I think timeout is
> measured in seconds) to simulate the 10 seconds that we have in NASes
> timeout. Then we put timeouts of 30 seconds, 1 minute ... without results.
>
> In the script which launches requests (bench), the timeout parameter is set
> to 10 seconds and I think is a reasonble time to resolve auth or acct.
>
>
> EXTRA INFO:
>
> We made some UDP tunning and
>
> /dev/udp udp_max_buff
>
> is set to 50000000(bytes) and in Radiator we also set
>
> SocketQueueLenght to 49000000.
>
> No improvement was obtained.
>
>
> As you can see, our auth has LDAP2 authentication, so to discard
> slow-connection-with-LDAP, we made a test with the same script (bench) but
> only acct (Mysql). 1000 requests were launched and only 600 were resolved.
> The clients obtain 400 "No reply's".
>
> Any experience or idea will be wellcomed.
>
> thanks and regards,
>
> jules
>
>
>
> -----Mensaje original-----
> De: Ingvar Berg (ERA) [mailto:[EMAIL PROTECTED]]
> Enviado el: lunes 5 de febrero de 2001 14:55
> Para: [EMAIL PROTECTED]
> Asunto: RE: (RADIATOR) TCP/UDP tunning for Solaris - IMPORTANT!
>
>
> Julio,
>
> You might try some "-timeout N" to allow for proper sequencing, i.e. wait
> for the Access-Accept before sending the accounting start.
>
> /Ingvar
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: den 2 februari 2001 09:05
> To: [EMAIL PROTECTED]
> Subject: RE: (RADIATOR) TCP/UDP tunning for Solaris - IMPORTANT!
>
>
> In our scenario:
>
> 3x Radiator servers (u5, u60, PII)
> 1x Arrowpoint LB (CSS11000)
> 1x Mysql (U250)
> 1x LDAP (U250)
> 3x Clients with radpwtst (U220R, Alpha)
>
> Clients send 1000 requests with radpwtst with -nostop. The clients are
> always at 100% CPU.
> They finish the requests in 150 seg, and we obtain a lot of "No reply"'s.
>
> The RADPOOL only updates 600 registers, and accounting insert 800 users (a
> lot of them with blank framedipaddress).
>
> These blank framedipaddres we think that they are due to radpwtst which
> sends always auth and acct packets. If an auth is not answered, radpwtst
> sends the acct and of course, RADONLINE is updated with an user with blank
> ip address because of auth was not resolved.
>
> Another thing is that with Radiator 2.16.3, we update 1000 of 1000 requests
> in RADONLINE (with duplicate ip's) RADPOOL has 600 registers updated and we
> haven't "No reply" messages in radpwtst client application.
>
> We upgrade Radiator to 2.17.1 to resolve the problem of "ip racing" in
> RADPOOL and, yes, we have not duplicates in RADONLINE but otherwise we
> obtain "No reply"'s, only 800 user registered in RADONLINE and, 'blank'
> framedipaddress in RADONLINE.
>
> We read some Radiator documentation that says '160 requests per second'. So
> certainly we are doing something wrong.
>
> All your experience will be appreciated, and help is needed urgently.
>
> regards,
> jules
>
>
> -----Mensaje original-----
> De: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Enviado el: jueves 1 de febrero de 2001 21:45
> Para: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Asunto: Re: (RADIATOR) TCP/UDP tunning for Solaris
>
>
>
> Hello Julio -
>
> On Thursday 01 February 2001 19:47, [EMAIL PROTECTED] wrote:
> > Hi all,
> >
> > We're benchmarking a Radiator architecture so,
> >
> > has anyone any recommendations about tunning tcp/udp system parameters in
>
> a
>
> > Solaris environment?
> >
> > has anyone any recommendations about SocketQueuelenght and its relation
> > with Solaris kernel parameters?
>
> You shouldn't normally have to make any changes.
--
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.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
