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.
