(RADIATOR) performance question

[Hugh Irvine]

Hello Julio -

Notice that I suggest running radpwtst on several seperate machines to the 
one that is running Radiator. This is the technique that we use to generate 
the indicative performance numbers in the manual.

You are quite correct in saying that radpwtst is not a high-performance 
radius packet generator - it is not. However, if you run two or three 
instances on four, five or six machines, you can still generate several 
hundred requests per second.

BTW - don't forget to use the "-notrace" flag when using radpwtst in this way.

regards

Hugh

On Wednesday 23 May 2001 19:18, julio.prada at bt.es wrote:
> 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.
===
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.