Hi Hugh,
first of all, let's me explain that our environment is a "test-environment"
and all the elements and hosts contained are dedicated exclusively to do
tests.
So we've not noise from another source, and all that happens would be what
we want to happen.
In our 'Production' environment the actual solution is not Radiator. It's
just another one and the role of Radiator is to work as a proxy. Actually
this solution will not be scalable and we're looking for a new Radius
product which acomplishes with several features.
Functionally, Radiator looks good solution because of the 'Authby LDAP' and
DYNADDRESS with MySQL.
In our 'Production' environment we receive a lot of radius requests and,
specially at 18:00 o'clock these requests are increased at 100 requests per
second (more or less).
In adittion, when our Radius service is resetted, a lot of incomming
requests must be resolved in a shot period of time (all users are
reconnecting...).
Before to put Radiator in 'Production' we want to test it in our laboratory.
The 'laboratory' scenario was described yet.
And our proposits are to emulate the requests from the NASes with radpwtst.
So a normal request will include Auth. The reason we use -nostop is to
emulate a user that try to connect from his home. So we're becnhmarking how
many users can connect in a minute, doing auth and acct.
The last test was to launch 1000 requests whith radpwtst -nostop -noacct,
and we obtained 600 registers in RADPOOL and 400 "No reply"'s.
This mail contain the .cfg we use and the script that we use to launch
requests.
All your help will be appreciated.
regards,
jules
-----Mensaje original-----
De: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Enviado el: sábado 3 de febrero de 2001 0:32
Para: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Asunto: Re: (RADIATOR) TCP/UDP tunning for Solaris - IMPORTANT!
Hello Julio -
On Friday 02 February 2001 19:05, [EMAIL PROTECTED] wrote:
> 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.
>
I have copied this to Mike so he can add his comments also.
Could you please explain what you are trying to simulate with your testing?
And could you also please send us copies of your configuaration file(s) (no
secrets), copies of your startup scripts, copies of your radpwtst scripts
and
any relevant trace 4 debug output?
If you are only trying to test maximum authentication rates, you should be
using "radpwtst -noacct .....". You should also set up a base-line scenario
with just an AuthBy TEST, or a simple AuthBy FILE to see how fast Radiator
runs with no outside influences, then you can add components to your testing
progressively and you will be able to see what components are taking the
most
time.
Note that Mike has done some work over the last couple of weeks on the
AddressAllocatorSQL code to improve its performance significantly.
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.
**********************************************
Noticia legal
Este mensaje electrónico contiene información de BT Telecomunicaciones S.A.
que es privada y confidencial, siendo para el uso exclusivo de la persona(s)
o entidades arriba mencionadas. Si usted no es el destinatario señalado, le
informamos que cualquier divulgación, copia, distribución o uso de los
contenidos está prohibida. Si usted ha recibido este mensaje por error, por
favor borre su contenido y comuníquenoslo en la dirección [EMAIL PROTECTED]
Gracias
MYSQL.CFG
BENCH
