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