(RADIATOR) performance question

[julio.prada at bt.es]

Hello Hugh,

Let me to be a little skeptical concerns to that idea. Multiple instances of
radpwtst seems to penalize a lot the performance of the host which does the
requests, and I'm not sure about how they share the host resources...

Anyway, as we discuss in previous mails, your recommendation was a limit
(aprox) of 3 instances of radpwtst. No more. But this seems not to be enough
volume of requests to simulate the peaks of requests that we receive from
the NASes.

The only way we have to test how the peaks affect Radiator server is in a
real environment. For example, we have a bonus-access-service which starts
at 18:00. The peak of requests sent by the NAS and the behavior is very
different from the tests we made in the laboratoy with radpwtst.

I think radpwtst is an amazing tool to test functionality, configuration and
so on. But a litle of improvemnet could be done to be used as a
performance-measuring tool.

regards,
jules

-----Mensaje original-----
De: Hugh Irvine [mailto:hugh at open.com.au]
Enviado el: miércoles 23 de mayo de 2001 10:25
Para: julio.prada at bt.es; radiator at osiris-it.nl; radiator at open.com.au
Asunto: Re: (RADIATOR) performance question



Hello Julio, Hello Feite -

The best way to exercise Radiator with radpwtst is to run several instances 
of radpwtst on one or more different machines to the one that is running 
Radiator. Start with one radpwtst to see how many requests per second 
Radiator will do, then add additional instances of radpwtst (possibly on two

or more machines) until you see no further increases in the number of 
requests per second being handled.

BTW - to easily see the number of requests per second from Radiator use the 
-trace -1 flag.

hth

Hugh


On Wednesday 23 May 2001 17:31, julio.prada at bt.es wrote:
> Hi all,
>
> we noticed that the performance bottleneck was due to the database in most
> of the cases(Postgre, mysql, oracle...) and tunning the db could help to
> improve it.
>
> Another thing is the radpwtst behavior. As we saw the radpwtst launches,
> for example, 1000 requests, one after other. Whether it doesn't obtain
> answer for the first request the next will not be sent and so on.
>
> That not will simulate the NASes behavior because they are not waiting for
> response between AAA requests.
>
> So a helpful tool could be a radpwtst able to send requests without
waiting
> time between requests (-nowait option).
>
> regards,
> jules
>
>
>
> -----Mensaje original-----
> De: radiator [mailto:radiator at osiris-it.nl]
> Enviado el: viernes 18 de mayo de 2001 11:00
> Para: radiator at open.com.au
> Asunto: (RADIATOR) performance question
>
>
> Hi,
>
> on my previous question I was told to take a look at the database design
> (indexes) to speed up performance.
>
> Now what if I have just configured the radiator with the basic examples
> from the goodies directory ?
>
> In that case I have :
>
> - an empty accounting table
> - a subscribers table with just one entry
>
> When now the radpwtst -iterations 1000 is run I guess I should see
> numbers that should represent the best performance there is to achieve
> because the accounting table contains NO indexes which is the fastest
> for insertion of records (you don't need to update the indexes when a
> record is inserted) and the subscribers table only contains 1 record so
> that should not be difficult to lookup.
>
> I found that on a Sparc Ultra-II 300  with postgresql 7.1 about 12
> requests a second can be handled which is rather low. The documentation
> chapter 24 says that a P-III-500 with Radhat linux does 70 requests a
> second, so I guess that a Sparc-Ultra-II-300 should be able to get near
> that number too.
>
> Who would share some thoughts ?
>
> Thanks,
>
>
> Feite Brekeveld
>
> ===
> 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.
>
> **********************************************
> 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
> postmaster at bt.es. Gracias.
> ===
> 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.

-- 
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 postmaster at bt.es. 
Gracias.
===
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.