Re: IMPORTANT - Re: (RADIATOR) Performance with RADIATOR

2001-03-20 Thread Hugh Irvine 


Hello Julio -

I think you should really start again from the beginning, following a plan 
something like this:

0. verify all network connections are running correctly
   (this may involve SUN and switch configurations)
   (we have observed severe network performance problems 
   due to 100-BaseT connections not negotiating correctly)

1. set up one machine running Radiator only

2. configure Radiator with a single AuthBy TEST clause

3. run Radiator with -trace -1

4. set up a second machine running radpwtst only

5. run radpwtst with "radpwtst -time -iterations 1000 -noacct"

6. observe the Radiator requests/second and record results

7. run 2 copies of the radpwtst test and record results

8. continue adding copies of radpwtst until Radiator peaks
   (this may require using 2 or more hosts for radpwtst)

9. note the maximum number of requests per second that Radiator can handle

10. configure a seperate machine running mysql

11. configure Radiator to use mysql 

12. repeat radpwtst's (still authentication only)

13. observe Radiator requests/second and record results

14. run Radiator configuration with Trace 4 and LogMicroseconds 

15. observe time taken for mysql requests in logfile

16. proceed with mysql tuning

17. continue testing and recording results

18. add Radiator accounting to tests

19. continue testing, tuning and recording results


I feel that this is the only way to be confident of what you are actually 
testing and observing.

hth

Hugh


On Tuesday 20 March 2001 20:08, [EMAIL PROTECTED] wrote:
> hi all,
>
> first, thanks to all for the recommendations.
>
> The first step was to discard that LDAP was decreasing performance.
> We change Authby LDAP2 for a Auth by File and no improvement was obtained.
>
> So, the key is MySQL tunning.
>
> We drop old tables and created new ones with Radiator218-goodies-script
> mysqlCreate.sql.
> It seems to introduce a new index for RADPOOL.
>
> We repeated the test (I was really excited!) but no improvement was
> obtained. :(
>
> The next step was to run two instances of Radiator (auth/acct) and no
> improvement was obtained.
>
> As Andy says, probably a hard tune of mySQL will be needed.
>
> Hugh: you say that an improvement of 80 r/s can be obtained running the
> new-db-creation-script. Anything else is needed?
>
> I can assure you that if Radiator can reach 80 request per second
> constantly, it will our new AAA software upgrade.
>
> I will notify to the list all the results obtained during this day and the
> canges we made.
>
> regards,
> jules
>
>
> -Mensaje original-
> De: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Enviado el: martes 20 de marzo de 2001 1:00
> Para: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Asunto: IMPORTANT - Re: (RADIATOR) Performance with RADIATOR
>
>
>
> Hello Julio -
>
> On Tuesday 20 March 2001 02:01, [EMAIL PROTECTED] wrote:
> > Hi all,
> >
> > we need to decide which radius server will upgrade our AAA plattform. Our
> > final choice is between Radiator and BSAC.
> >
> > A feature-table has been elaborated and checked during the last months.
>
> The
>
> > last check-item is about performance in resolving radius-clients
> > requests.
> >
> > So the same test was done in the same conditions for BSAC and Radiator:
> >
> > - U420R with 2 processors, 1GB memory (Radius Server)
> > - U220R with 1 processor, 512MG memory (Radius client with radpwtst)
> >
> > A radpwtst request was executed with 250 iterations.
> >
> > The results are:
> >
> > - BSAC finished in 7 sec.
> > - Radiator finished in 23 sec.
> >
> > During the last months we made tunning of Radiator on these points:
> > - hardware
> > - LDAP
> > - MySQL
> > - UDP
> >
> > but it seems like the perl language is the main problem to improve
> > performance.
> >
> > We launch Radiator with "Trace -1" and monitoring it, we noticed that
> > almost all the time the peak of requests per second is 30.
> >
> > so,
> >
> > Anybody can tell us how to improve performace with Radiator?
> >
> > Does exist the posibility of execute a like-compiled instance of
> > Radiator?
> >
> > Do you have in mind to upgrade Radiator to a multithread-compiled
> > release?
>
> There are a number of issues to consider regarding Radiator performance,
> mostly to do with external factors like databases and so on.
>
> It is interesting that in recent tests using identical hardware, we
> initially
> saw about the same 30 requests per second, also using MySQL. However, we
> found that there was enormous improvement to be had simply by tuning

RE: (RADIATOR) Performance with RADIATOR

2001-03-20 Thread julio . prada 

yes, the same lan, the same machine, the same switch.

regards,
jules

-Mensaje original-
De: Andy De Petter [mailto:[EMAIL PROTECTED]]
Enviado el: martes 20 de marzo de 2001 17:04
Para: Radiator Mailing
Asunto: RE: (RADIATOR) Performance with RADIATOR



Owh, and are your database server, and radius server, on the same
LAN/switch?

-a

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Andy De Petter
> Sent: dinsdag 20 maart 2001 15:23
> To: [EMAIL PROTECTED]
> Cc: Radiator Mailing
> Subject: RE: (RADIATOR) Performance with RADIATOR
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> > Behalf Of [EMAIL PROTECTED]
> > Sent: dinsdag 20 maart 2001 13:43
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: RE: (RADIATOR) Performance with RADIATOR
> >
> >
> > We try to do some MySQL tunning with next variables:
> >
> >  # safe_mysqld -O key_buffer=32M -O table_cache=254 -O sort_buffer=8M -O
> > record_buffer=2M &
> >
>
> Also increase the max_connections (upto 1024), wait_timeout (upto 512),
> max_connect_errors (upto 9) ... and you may increase the
> table_cache
> upto 1024
>
> -a
>
>
> ===
> 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.
>


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

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

RE: (RADIATOR) Performance with RADIATOR

2001-03-20 Thread Andy De Petter 


Owh, and are your database server, and radius server, on the same
LAN/switch?

-a

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Andy De Petter
> Sent: dinsdag 20 maart 2001 15:23
> To: [EMAIL PROTECTED]
> Cc: Radiator Mailing
> Subject: RE: (RADIATOR) Performance with RADIATOR
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> > Behalf Of [EMAIL PROTECTED]
> > Sent: dinsdag 20 maart 2001 13:43
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: RE: (RADIATOR) Performance with RADIATOR
> >
> >
> > We try to do some MySQL tunning with next variables:
> >
> >  # safe_mysqld -O key_buffer=32M -O table_cache=254 -O sort_buffer=8M -O
> > record_buffer=2M &
> >
>
> Also increase the max_connections (upto 1024), wait_timeout (upto 512),
> max_connect_errors (upto 9) ... and you may increase the
> table_cache
> upto 1024
>
> -a
>
>
> ===
> 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.
>


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

RE: (RADIATOR) Performance with RADIATOR

2001-03-20 Thread Andy De Petter 


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of [EMAIL PROTECTED]
> Sent: dinsdag 20 maart 2001 13:43
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: (RADIATOR) Performance with RADIATOR
>
>
> We try to do some MySQL tunning with next variables:
>
>  # safe_mysqld -O key_buffer=32M -O table_cache=254 -O sort_buffer=8M -O
> record_buffer=2M &
>

Also increase the max_connections (upto 1024), wait_timeout (upto 512),
max_connect_errors (upto 9) ... and you may increase the table_cache
upto 1024

-a


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

RE: (RADIATOR) Performance with RADIATOR

2001-03-20 Thread julio . prada 

Hi Ingvar,

As you say, the bottleneck will not be in Authby LDAP. The auth request
seems to be faster than the acct request. So the acct will slow down general
performance also requests per second.

We try to do some MySQL tunning with next variables:

 # safe_mysqld -O key_buffer=32M -O table_cache=254 -O sort_buffer=8M -O
record_buffer=2M &

but no improvement was obtained.
We double the values and no improvement was obtained too.

So, if anybody uses MySQL for acct, could tell us which variables is they
using?
Does anybody know another way to create indexes different from
goodies-script and improve performance?

Hugh: Do you remember the changes to MySQL to obtain 80 r/s ?

regards,
jules

-Mensaje original-
De: Ingvar Berg (ERA) [mailto:[EMAIL PROTECTED]]
Enviado el: martes 20 de marzo de 2001 12:27
Para: [EMAIL PROTECTED]
Asunto: RE: (RADIATOR) Performance with RADIATOR


Hi Julio,

We have a configuration with separate processes for authentication and
accounting, running on an Enterprise 420 box. Authentication uses iPlanet
Directory 4.x, and accounting is both to local file and to another radius
server. With only authentication, we have around 80 auths/sec, but with
accounting it drops to below 50 sessions/sec.
I guess that with the latest suggestion for improvement of AuthRADIUS.pm,
that can improve quite a bit.

/Ingvar

PS.
To see an improvement in performance with separate auth and acct processes,
I think you need to run more than one instance of radpwtst (and on a
separate box, of course :)
DS

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: den 20 mars 2001 10:08
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: IMPORTANT - Re: (RADIATOR) Performance with RADIATOR


hi all,

first, thanks to all for the recommendations.

The first step was to discard that LDAP was decreasing performance.
We change Authby LDAP2 for a Auth by File and no improvement was obtained.

So, the key is MySQL tunning.

We drop old tables and created new ones with Radiator218-goodies-script
mysqlCreate.sql.
It seems to introduce a new index for RADPOOL.

We repeated the test (I was really excited!) but no improvement was
obtained. :(

The next step was to run two instances of Radiator (auth/acct) and no
improvement was obtained.

As Andy says, probably a hard tune of mySQL will be needed.

Hugh: you say that an improvement of 80 r/s can be obtained running the
new-db-creation-script. Anything else is needed?

I can assure you that if Radiator can reach 80 request per second
constantly, it will our new AAA software upgrade.

I will notify to the list all the results obtained during this day and the
canges we made.

regards,
jules


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

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

RE: (RADIATOR) Performance with RADIATOR

2001-03-20 Thread Ingvar Berg (ERA) 

Hi Julio,

We have a configuration with separate processes for authentication and accounting, 
running on an Enterprise 420 box. Authentication uses iPlanet Directory 4.x, and 
accounting is both to local file and to another radius server. With only 
authentication, we have around 80 auths/sec, but with accounting it drops to below 50 
sessions/sec.
I guess that with the latest suggestion for improvement of AuthRADIUS.pm, that can 
improve quite a bit.

/Ingvar

PS.
To see an improvement in performance with separate auth and acct processes, I think 
you need to run more than one instance of radpwtst (and on a separate box, of course :)
DS

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: den 20 mars 2001 10:08
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: IMPORTANT - Re: (RADIATOR) Performance with RADIATOR


hi all,

first, thanks to all for the recommendations.

The first step was to discard that LDAP was decreasing performance.
We change Authby LDAP2 for a Auth by File and no improvement was obtained.

So, the key is MySQL tunning.

We drop old tables and created new ones with Radiator218-goodies-script
mysqlCreate.sql.
It seems to introduce a new index for RADPOOL.

We repeated the test (I was really excited!) but no improvement was
obtained. :(

The next step was to run two instances of Radiator (auth/acct) and no
improvement was obtained.

As Andy says, probably a hard tune of mySQL will be needed.

Hugh: you say that an improvement of 80 r/s can be obtained running the
new-db-creation-script. Anything else is needed?

I can assure you that if Radiator can reach 80 request per second
constantly, it will our new AAA software upgrade.

I will notify to the list all the results obtained during this day and the
canges we made.

regards,
jules


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

RE: IMPORTANT - Re: (RADIATOR) Performance with RADIATOR

2001-03-20 Thread julio . prada 

hi all,

first, thanks to all for the recommendations.

The first step was to discard that LDAP was decreasing performance.
We change Authby LDAP2 for a Auth by File and no improvement was obtained.

So, the key is MySQL tunning.

We drop old tables and created new ones with Radiator218-goodies-script
mysqlCreate.sql.
It seems to introduce a new index for RADPOOL.

We repeated the test (I was really excited!) but no improvement was
obtained. :(

The next step was to run two instances of Radiator (auth/acct) and no
improvement was obtained.

As Andy says, probably a hard tune of mySQL will be needed.

Hugh: you say that an improvement of 80 r/s can be obtained running the
new-db-creation-script. Anything else is needed?

I can assure you that if Radiator can reach 80 request per second
constantly, it will our new AAA software upgrade.

I will notify to the list all the results obtained during this day and the
canges we made.

regards,
jules


-Mensaje original-
De: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Enviado el: martes 20 de marzo de 2001 1:00
Para: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Asunto: IMPORTANT - Re: (RADIATOR) Performance with RADIATOR



Hello Julio -

On Tuesday 20 March 2001 02:01, [EMAIL PROTECTED] wrote:
> Hi all,
>
> we need to decide which radius server will upgrade our AAA plattform. Our
> final choice is between Radiator and BSAC.
>
> A feature-table has been elaborated and checked during the last months.
The
> last check-item is about performance in resolving radius-clients requests.
>
> So the same test was done in the same conditions for BSAC and Radiator:
>
> - U420R with 2 processors, 1GB memory (Radius Server)
> - U220R with 1 processor, 512MG memory (Radius client with radpwtst)
>
> A radpwtst request was executed with 250 iterations.
>
> The results are:
>
> - BSAC finished in 7 sec.
> - Radiator finished in 23 sec.
>
> During the last months we made tunning of Radiator on these points:
> - hardware
> - LDAP
> - MySQL
> - UDP
>
> but it seems like the perl language is the main problem to improve
> performance.
>
> We launch Radiator with "Trace -1" and monitoring it, we noticed that
> almost all the time the peak of requests per second is 30.
>
> so,
>
> Anybody can tell us how to improve performace with Radiator?
>
> Does exist the posibility of execute a like-compiled instance of Radiator?
>
> Do you have in mind to upgrade Radiator to a multithread-compiled release?
>

There are a number of issues to consider regarding Radiator performance, 
mostly to do with external factors like databases and so on.

It is interesting that in recent tests using identical hardware, we
initially 
saw about the same 30 requests per second, also using MySQL. However, we 
found that there was enormous improvement to be had simply by tuning the 
database and improving the indexes. In this particular case we saw the
number 
of requests jump from 30 per second to 80 per second with no other changes. 

I also have some comments about common misunderstandings regarding Perl. 

First, Perl *is* compiled, but it is compiled at run time, not in some 
preliminary step prior to execution. Therefore, Radiator takes a few seconds

to start up while the code is compiled, but thereafter it is as fast (or 
faster for some operations) than a compiled language. Performance
limitations 
in our experience with thousands of installations of Radiator has never been

due to Perl.

Second, multithreading - this comes up from time to time, and yes it is 
something we are considering once the support for multithreading is
certified 
as "ready for production". Note however that multithreading in and of itself

is not a panacea, and we have had comments from users of other products that

multithreading can also cause severe problems, like when a database becomes 
unavailable and all of the process slots are exhausted due to threads
waiting 
for completion. This failure mode is particularily unpleasant, as it 
generally means that the box is locked up with no way to restart it short of

a power cycle.

Now, in your situation, I think you should do the following:

1. download and install Radiator 2.18

2. use the new high-resolution timing feature to examine the actual 
exectution times of your LDAP and SQL queries. See section 6.10.2 in the 
Radiator 2.18 reference manual

3. use the new indexes and SQL queries for MySQL in Radiator 2.18

4. have your DBA verify what other indexes should be added to your database

5. make sure you use the -notrace option with "radpwtst -notrace ."

6. you should consider running two instances of Radiator, one for 
authentication and the other for accounting

As other contributors to the list have noted, you should be able to get 
*much* better performance from your system than you are currently seeing.

rega

RE: (RADIATOR) Performance with RADIATOR

2001-03-19 Thread Mike McCauley 


--- Forwarded mail from [EMAIL PROTECTED]

Date: Tue, 20 Mar 2001 17:40:29 +1100 (EST)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: BOUNCE [EMAIL PROTECTED]:Non-member submission from ["Andy De
Petter" <[EMAIL PROTECTED]>]

>From mikem  Tue Mar 20 17:40:23 2001
Received: by oscar.open.com.au (8.9.0/8.9.0) id RAA07771
for [EMAIL PROTECTED]; Tue, 20 Mar 2001 17:40:23 +1100 (EST)
>Received: from mail.krameria.net (mail.krameria.net [194.78.241.3]) by
perki.connect.com.au with ESMTP id RAA27827
  (8.8.8/IDA-1.7 for <[EMAIL PROTECTED]>); Tue, 20 Mar 2001 17:12:24 +1100
(EST)
Received: from mail.krameria.net (mail.krameria.net [194.78.241.3]) by
perki.connect.com.au with ESMTP id RAA27827
  (8.8.8/IDA-1.7 for <[EMAIL PROTECTED]>); Tue, 20 Mar 2001 17:12:24 +1100
(EST)
Received: from warp-core.skynet.be ([195.238.2.25] helo=Sarabi)
by mail.krameria.net with asmtp (Exim 3.20 #1)
id 14fFPV-0001Of-00; Tue, 20 Mar 2001 07:14:25 +0100
From: "Andy De Petter" <[EMAIL PROTECTED]>
To: "Steve Roderick" <[EMAIL PROTECTED]>
Cc: "Radiator Mailing" <[EMAIL PROTECTED]>
Subject: RE: (RADIATOR) Performance with RADIATOR
Date: Tue, 20 Mar 2001 07:12:19 +0100
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain;
charset="us-ascii"


>
>
> I was referring to the MySQL/LDAP part. I am not familiar with
> LDAP at all
> so I couldn't offer any advise on it. But, MySQL is VERY fast. We can do
> almost 2000 lookups per second on our MySQL servers (we do this
> with Apache
> querying the DB). The problems come in when you are doing complex or data
> heavy inserts into MySQL. These are more common in Radius accounting. If
> you are running into problems with performance you should look
> into running
> Radiator and MySQL on different machines. Your DB should certainly be
> running on RAID disk subsystem.
>

Nothing that works, based on SQL, beats LDAP, in query speed. :)

-Andy


--
"For nothing can seem foul to those that win."
  - Henry IV, Pt1, Act 5, Sc 1





---End of forwarded mail from [EMAIL PROTECTED]

-- 
Mike McCauley   [EMAIL PROTECTED]
Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia   http://www.open.com.au
Phone +61 3 9598-0985   Fax   +61 3 9598-0955

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc 
on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X
===
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.

RE: (RADIATOR) Performance with RADIATOR

2001-03-19 Thread Andy De Petter 



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of [EMAIL PROTECTED]
> Sent: maandag 19 maart 2001 20:19
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: (RADIATOR) Performance with RADIATOR
>
>
> At 04:01 PM 3/19/2001 +0100, [EMAIL PROTECTED] wrote:
> >The results are:
> >
> >- BSAC finished in 7 sec.
> >- Radiator finished in 23 sec.
> >
> >We launch Radiator with "Trace -1" and monitoring it, we noticed that
> almost
> >all the time the peak of requests per second is 30.
>
>
> We have gotten over 500 requests per second from Radiator when hitting it
> with multiple clients. We can do over 200 from a single client.
>
> Are you including accounting in your requests or are you purely looking at
> auths?
> We send complete requests (auth, acct on, acct off)
>

Shouldn't be a problem.

>
> What are the specifics of what you are testing?
>
> We send a complete request to a Radiator server which has MySQL
> in local and
> LDAP in remote server
>
> We use Solaris 2.6 and, what do you refer to with 'specifics'?
> hw? sw? lan?

Make sure your radius and your SQL server, is on the same LAN (preferrably
even the same switch).

>
>
> How many requests per second can your DB handle?
> I don't know how many. It's a MySQL server in the same machine
> that Radiator
> (1GB memory, 2 processors) and it only hosts Radiator database
>
> Do U recommend DB tunning?.
>

Yes, MySQL needs to be tuned, to be able to accept lots of queries, and to
make the DB response relatively fast.  You should consider, having indeces
for every column you plan to search on, raise the amount of maximum
concurrent connections, increase the table cache, increase the wait timeout,
increase the max connect errors, increase the key buffers, skip name
resolving, etc 

Please refer to the MySQL documentation, to fine-tune your server.

-Andy

--

 Andy De Petter _,'|_.-''``-...___..--';
   Skynet  Operations  /, \'.  _..-' ,  ,--...--'''
  < \   .`--'''  ` /|
  Tel +32 (0)2 7061311 `-,;'  ;   ; ;
  Fax +32 (0)2 7061312__...--'' __...--_..'  .;.'
 (,__'''  (,..--''
*** DISCLAIMER ***
This e-mail and any attachments thereto may contain information, which
is confidential and/or protected by intellectual property rights and
are intended for the sole use of the recipient(s) named above. Any use
of the information contained herein (including, but not limited to,
total or partial reproduction, communication or distribution in any
form) by persons other than the designated recipient(s) is prohibited.
If you have received this e-mail in error, please notify the sender
either by telephone or by e-mail and delete the material from any
computer. Thank you for your cooperation.


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

RE: (RADIATOR) Performance with RADIATOR

2001-03-19 Thread Steve Roderick 

At 08:18 PM 3/19/2001 +0100, [EMAIL PROTECTED] wrote:
>We have gotten over 500 requests per second from Radiator when hitting it
>with multiple clients. We can do over 200 from a single client.
>
>Are you including accounting in your requests or are you purely looking at
>auths?
>We send complete requests (auth, acct on, acct off)

Sorry, I was really looking at benchmark numbers and not real world usage. 
The numbers that I was thinking of were related to our benchmarking 
Radiator with a minimal config and certainly no accounting. This was back 
when we were determining our hardware requirements for deploying it.


>What are the specifics of what you are testing?
>
>We send a complete request to a Radiator server which has MySQL in local and
>LDAP in remote server
>
>We use Solaris 2.6 and, what do you refer to with 'specifics'? hw? sw? lan?
>How many requests per second can your DB handle?
>I don't know how many. It's a MySQL server in the same machine that Radiator
>(1GB memory, 2 processors) and it only hosts Radiator database


I was referring to the MySQL/LDAP part. I am not familiar with LDAP at all 
so I couldn't offer any advise on it. But, MySQL is VERY fast. We can do 
almost 2000 lookups per second on our MySQL servers (we do this with Apache 
querying the DB). The problems come in when you are doing complex or data 
heavy inserts into MySQL. These are more common in Radius accounting. If 
you are running into problems with performance you should look into running 
Radiator and MySQL on different machines. Your DB should certainly be 
running on RAID disk subsystem.

>Do U recommend DB tunning?.

It is definitely one of the first places to look. I would guess that the 
LDAP server could be a big question mark as well. Looking at the Radiator 
reference manual the numbers for LDAP auths per second is significantly 
less than SQL, although I don't know that these numbers have been updated 
since a lot of the LDAP changes have been made, you would have to ask Hugh.

The first thing I would do is split the auth and acct job between two 
processes. Then you can get a better idea of where the problem is. You 
should be spending a lot more time on acct than auth, if you aren't then it 
is probably and LDAP issue. (This is because acct gets two calls for every 
auth [start and stop]).

Also, as your SQL table gets larger from the accounting records you will 
want to groom it. I noticed awhile back that someone had described their 
config where they log to SQL on one machine and then replicate the records 
to there final home on a seperate DB server, they then remove them from the 
original log host. This keeps the number of records to a minimum and stops 
the DB table size from affecting the performance of Radiator.

Something to think about: if 10 requests per second isn't enough for your 
needs you should look into load balancing across multiple Radius servers. 
Certainly if you have that many requests you should have a second server 
anyway.

Whew, I wrote too much, hope it was at least somewhat helpful.

Steve


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

IMPORTANT - Re: (RADIATOR) Performance with RADIATOR

2001-03-19 Thread Hugh Irvine 


Hello Julio -

On Tuesday 20 March 2001 02:01, [EMAIL PROTECTED] wrote:
> Hi all,
>
> we need to decide which radius server will upgrade our AAA plattform. Our
> final choice is between Radiator and BSAC.
>
> A feature-table has been elaborated and checked during the last months. The
> last check-item is about performance in resolving radius-clients requests.
>
> So the same test was done in the same conditions for BSAC and Radiator:
>
> - U420R with 2 processors, 1GB memory (Radius Server)
> - U220R with 1 processor, 512MG memory (Radius client with radpwtst)
>
> A radpwtst request was executed with 250 iterations.
>
> The results are:
>
> - BSAC finished in 7 sec.
> - Radiator finished in 23 sec.
>
> During the last months we made tunning of Radiator on these points:
> - hardware
> - LDAP
> - MySQL
> - UDP
>
> but it seems like the perl language is the main problem to improve
> performance.
>
> We launch Radiator with "Trace -1" and monitoring it, we noticed that
> almost all the time the peak of requests per second is 30.
>
> so,
>
> Anybody can tell us how to improve performace with Radiator?
>
> Does exist the posibility of execute a like-compiled instance of Radiator?
>
> Do you have in mind to upgrade Radiator to a multithread-compiled release?
>

There are a number of issues to consider regarding Radiator performance, 
mostly to do with external factors like databases and so on.

It is interesting that in recent tests using identical hardware, we initially 
saw about the same 30 requests per second, also using MySQL. However, we 
found that there was enormous improvement to be had simply by tuning the 
database and improving the indexes. In this particular case we saw the number 
of requests jump from 30 per second to 80 per second with no other changes. 

I also have some comments about common misunderstandings regarding Perl. 

First, Perl *is* compiled, but it is compiled at run time, not in some 
preliminary step prior to execution. Therefore, Radiator takes a few seconds 
to start up while the code is compiled, but thereafter it is as fast (or 
faster for some operations) than a compiled language. Performance limitations 
in our experience with thousands of installations of Radiator has never been 
due to Perl.

Second, multithreading - this comes up from time to time, and yes it is 
something we are considering once the support for multithreading is certified 
as "ready for production". Note however that multithreading in and of itself 
is not a panacea, and we have had comments from users of other products that 
multithreading can also cause severe problems, like when a database becomes 
unavailable and all of the process slots are exhausted due to threads waiting 
for completion. This failure mode is particularily unpleasant, as it 
generally means that the box is locked up with no way to restart it short of 
a power cycle.

Now, in your situation, I think you should do the following:

1. download and install Radiator 2.18

2. use the new high-resolution timing feature to examine the actual 
exectution times of your LDAP and SQL queries. See section 6.10.2 in the 
Radiator 2.18 reference manual

3. use the new indexes and SQL queries for MySQL in Radiator 2.18

4. have your DBA verify what other indexes should be added to your database

5. make sure you use the -notrace option with "radpwtst -notrace ."

6. you should consider running two instances of Radiator, one for 
authentication and the other for accounting

As other contributors to the list have noted, you should be able to get 
*much* better performance from your system than you are currently seeing.

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.

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

RE: (RADIATOR) Performance with RADIATOR

2001-03-19 Thread julio . prada 

At 04:01 PM 3/19/2001 +0100, [EMAIL PROTECTED] wrote:
>The results are:
>
>- BSAC finished in 7 sec.
>- Radiator finished in 23 sec.
>
>We launch Radiator with "Trace -1" and monitoring it, we noticed that
almost
>all the time the peak of requests per second is 30.


We have gotten over 500 requests per second from Radiator when hitting it
with multiple clients. We can do over 200 from a single client.

Are you including accounting in your requests or are you purely looking at
auths?
We send complete requests (auth, acct on, acct off)


What are the specifics of what you are testing?

We send a complete request to a Radiator server which has MySQL in local and
LDAP in remote server

We use Solaris 2.6 and, what do you refer to with 'specifics'? hw? sw? lan?


How many requests per second can your DB handle?
I don't know how many. It's a MySQL server in the same machine that Radiator
(1GB memory, 2 processors) and it only hosts Radiator database

Do U recommend DB tunning?.


Steve



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


** 
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

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

Re: (RADIATOR) Performance with RADIATOR

2001-03-19 Thread Steve Roderick 

At 04:01 PM 3/19/2001 +0100, [EMAIL PROTECTED] wrote:
>The results are:
>
>- BSAC finished in 7 sec.
>- Radiator finished in 23 sec.
>
>We launch Radiator with "Trace -1" and monitoring it, we noticed that almost
>all the time the peak of requests per second is 30.


We have gotten over 500 requests per second from Radiator when hitting it 
with multiple clients. We can do over 200 from a single client. Are you 
including accounting in your requests or are you purely looking at auths? 
What are the specifics of what you are testing? How many requests per 
second can your DB handle?

Steve



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