Re: [RADIATOR] Performance logging

[A . L . M . Buxey]

Hi,

> Somewhat yes, I get the idea of anonymizing user’s identity with PEAP, but 
> for example with demo test certificates bundled with Radiator, PEAP-TLS 
> takes 15 rounds for a single EAP authentication.

well, PEAP itself takes around 12-14 rounds - the EAP-TLS part is short. 
however,
unless the client is correctly configured it will do the PEAP part with any 
RADIUS server
that has a CA the client knows (hello any of those public CAs) - and thus will
provide that server with the clients public-component TLS cert

alan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Tuure Vartiainen]

Hi,

> On 04 Apr 2016, at 11:24, Hartmaier Alexander 
>  wrote:
> 
> On 2016-03-30 15:10, Tuure Vartiainen wrote:
>> 
>>> On 30 Mar 2016, at 14:55, Hartmaier Alexander 
>>>  wrote:
>>> 
>>> we use PEAP-TLS, EAP-PEAP as outer EAP type with EAP-TLS as inner.
>>> Not sure if the outher EAP-PEAP adds any real security as the Radiator
>>> cert is the same one for both types as it only hides the transmission of
>>> the user cert which can be classified like a public key imho.
>>> 
>> Ack.
> Would you say that using PEAP-TLS for both wired and wireless auth is
> overkill even when both are considered sniffable?
> 

Somewhat yes, I get the idea of anonymizing user’s identity with PEAP, but 
for example with demo test certificates bundled with Radiator, PEAP-TLS 
takes 15 rounds for a single EAP authentication.

>> 
>> We’ll add a feature, which will allow the total time along with an on-demand
>> timing to be used through %{...} special format in AuthLogs etc.
> Thanks! Please inform me when it has landed in the patches.
> 

Yes, I’ll reply here.


BR
-- 
Tuure Vartiainen 

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, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Hartmaier Alexander]

Hi,

On 2016-03-30 15:10, Tuure Vartiainen wrote:
> Hi,
>
>> On 30 Mar 2016, at 14:55, Hartmaier Alexander 
>>  wrote:
>>
>> we use PEAP-TLS, EAP-PEAP as outer EAP type with EAP-TLS as inner.
>> Not sure if the outher EAP-PEAP adds any real security as the Radiator
>> cert is the same one for both types as it only hides the transmission of
>> the user cert which can be classified like a public key imho.
>>
> Ack.
Would you say that using PEAP-TLS for both wired and wireless auth is
overkill even when both are considered sniffable?

>
>> I've already tuned the EAPTLS_MaxFragmentSize to have as few roundtrips
>> as possible (1350 for the outer PEAP and 1300 for the inner EAP-TLS).
>>
> Yes, unfortunately beside that the only real option to minimize a delay of an 
> EAP authentication is to
> minimize the round-trips either by sending less certificate data or
> by using an EAP method with fewer rounds.
>
>> You see how I calculate the response_time in my email yesterday.
>>
> $p->{RecvTime} is set with a time of receive when an Access-Request is 
> received, so
>
> $message->{response_time} = Radius::Util::timeInterval(
> $p->{RecvTime},
> $p->{RecvTimeMicros}, Radius::Util::getTimeHires());
>
> will calculate a response time only for that Access-Request.
>
>
> When running Radiator with Trace 4 or 5, a total time for an EAP
> authentication can be seen in the log.
>
> E.g.
>
> Wed Mar 30 12:55:58 2016 816812: DEBUG: EAP Success, elapsed time 0.71221
>
> We’ll add a feature, which will allow the total time along with an on-demand
> timing to be used through %{...} special format in AuthLogs etc.
Thanks! Please inform me when it has landed in the patches.

>
>
> BR
BR


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Tuure Vartiainen]

Hi,

> On 30 Mar 2016, at 14:55, Hartmaier Alexander 
>  wrote:
> 
> we use PEAP-TLS, EAP-PEAP as outer EAP type with EAP-TLS as inner.
> Not sure if the outher EAP-PEAP adds any real security as the Radiator
> cert is the same one for both types as it only hides the transmission of
> the user cert which can be classified like a public key imho.
> 

Ack.

> I've already tuned the EAPTLS_MaxFragmentSize to have as few roundtrips
> as possible (1350 for the outer PEAP and 1300 for the inner EAP-TLS).
> 

Yes, unfortunately beside that the only real option to minimize a delay of an 
EAP authentication is to 
minimize the round-trips either by sending less certificate data or 
by using an EAP method with fewer rounds.

> You see how I calculate the response_time in my email yesterday.
> 

$p->{RecvTime} is set with a time of receive when an Access-Request is 
received, so 

$message->{response_time} = Radius::Util::timeInterval(
   $p->{RecvTime},
   $p->{RecvTimeMicros}, Radius::Util::getTimeHires());

will calculate a response time only for that Access-Request.


When running Radiator with Trace 4 or 5, a total time for an EAP 
authentication can be seen in the log.

E.g.

Wed Mar 30 12:55:58 2016 816812: DEBUG: EAP Success, elapsed time 0.71221

We’ll add a feature, which will allow the total time along with an on-demand 
timing to be used through %{...} special format in AuthLogs etc.


BR
-- 
Tuure Vartiainen 

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, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Hartmaier Alexander]

Hi Tuure,
we use PEAP-TLS, EAP-PEAP as outer EAP type with EAP-TLS as inner.
Not sure if the outher EAP-PEAP adds any real security as the Radiator
cert is the same one for both types as it only hides the transmission of
the user cert which can be classified like a public key imho.

I've already tuned the EAPTLS_MaxFragmentSize to have as few roundtrips
as possible (1350 for the outer PEAP and 1300 for the inner EAP-TLS).

You see how I calculate the response_time in my email yesterday.

Best regards, Alex

On 2016-03-30 13:27, Tuure Vartiainen wrote:
> Hi,
>
>> On 30 Mar 2016, at 14:13, Hartmaier Alexander 
>>  wrote:
>>
>> yes this is the total auth time. Is one second a usual value for a
>> PEAP-TLS auth?
>>
> just out of curiosity, how do you calculate the total auth time?
>
> An EAP authentication takes around 4-10 round-trips depending on
> an EAP method and an amount of (certificate) data transferred.
>
> If you time the authentication from the receive time of the first 
> Access-Request
> to the final Access-Accept, your total time also includes transmission
> delays of those EAP round-trips between an EAP supplicant and Radiator.
>
> Does PEAP-TLS mean, that you are using EAP-PEAP with EAP-TLS as an innner EAP 
> method
> or EAP-PEAP with EAP-MSCHAPv2?
>
>
> BR



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Tuure Vartiainen]

Hi,

> On 30 Mar 2016, at 14:13, Hartmaier Alexander 
>  wrote:
> 
> yes this is the total auth time. Is one second a usual value for a
> PEAP-TLS auth?
> 

just out of curiosity, how do you calculate the total auth time?

An EAP authentication takes around 4-10 round-trips depending on 
an EAP method and an amount of (certificate) data transferred.

If you time the authentication from the receive time of the first 
Access-Request 
to the final Access-Accept, your total time also includes transmission 
delays of those EAP round-trips between an EAP supplicant and Radiator.

Does PEAP-TLS mean, that you are using EAP-PEAP with EAP-TLS as an innner EAP 
method 
or EAP-PEAP with EAP-MSCHAPv2?


BR
-- 
Tuure Vartiainen 

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, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Hugh Irvine]

Hello Alex -

It depends on what you are looking at.

EAP involves multiple RADIUS messages to and from the end user device and 
Radiator.

If you are looking at the overall response time from the initial RADIUS 
Access-Request, through all of the EAP back and forth, to the ultimate 
Access-Accept, there really is nothing you can do.

If on the other hand you are looking only at the inner EAP request and the 
associated authentication process, as Tuure says, any delays are likely to be 
backend lookups.

regards

Hugh



> On 30 Mar 2016, at 20:57, Tuure Vartiainen  wrote:
> 
> Hi,
> 
>> On 29 Mar 2016, at 11:53, Hartmaier Alexander 
>>  wrote:
>> 
>> I've copied the calculation code to my LogFormatHook code:
>> 
>> $message->{response_time} = Radius::Util::timeInterval( \
>>$p->{RecvTime}, \
>>$p->{RecvTimeMicros}, Radius::Util::getTimeHires()); \
>> 
>> I'd still prefer if that float was available with a placeholder variable.
>> 
>> It shows what I was expecting, EAP authentication is slow.
>> Any pointers where I can start optimizing the EAP auth performance?
>> 
> 
> hard to say without seeing your configuration and Trace 4 (DEBUG) log 
> of a single request including microseconds (LogMicroseconds).
> 
> I assume that those timings are for the last Access-Request of 
> EAP authentication which produces either Access-Accept or Access-Reject.
> 
> Usually most of the time goes to a user lookup from a backend.
> 
> 
> BR
> -- 
> Tuure Vartiainen 
> 
> 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, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
> NetWare etc.
> 
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
h...@open.com.au

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, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER, SIM, etc. 
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Tuure Vartiainen]

Hi,

> On 29 Mar 2016, at 11:53, Hartmaier Alexander 
>  wrote:
> 
> I've copied the calculation code to my LogFormatHook code:
> 
> $message->{response_time} = Radius::Util::timeInterval( \
> $p->{RecvTime}, \
> $p->{RecvTimeMicros}, Radius::Util::getTimeHires()); \
> 
> I'd still prefer if that float was available with a placeholder variable.
> 
> It shows what I was expecting, EAP authentication is slow.
> Any pointers where I can start optimizing the EAP auth performance?
> 

hard to say without seeing your configuration and Trace 4 (DEBUG) log 
of a single request including microseconds (LogMicroseconds).

I assume that those timings are for the last Access-Request of 
EAP authentication which produces either Access-Accept or Access-Reject.

Usually most of the time goes to a user lookup from a backend.


BR
-- 
Tuure Vartiainen 

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, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Hartmaier Alexander]

Thanks for the extensive infos!

I've copied the calculation code to my LogFormatHook code:

$message->{response_time} = Radius::Util::timeInterval( \
   $p->{RecvTime}, \
   $p->{RecvTimeMicros}, Radius::Util::getTimeHires()); \

I'd still prefer if that float was available with a placeholder variable.

Works like a charm:

[cid:part1.05080303.09030203@t-systems.at]

It shows what I was expecting, EAP authentication is slow.
Any pointers where I can start optimizing the EAP auth performance?

Thanks, Alex


On 2016-03-26 09:31, Heikki Vatiainen wrote:

On 03/24/2016 01:18 PM, Hartmaier Alexander wrote:



If you already calculate the response time can you please also expose it
via a special placeholder character?



In the current patches there's the possibility to log RecvTime and
RecvTimeMicros which are the second and microsecond of the time when the
request was received. These are variables stamped in the current request
and with the patches you can do %{ReplyVar:RecvTime} to e.g., log them.

What you could do is to log these two variables and the current time and
let the log processing system do the math.

Currently the response time calculation happens just before the reply is
sent, so it's not available earlier, for example, for authentication
logging.



I'd add this value to the AuthLog which goes via RabbitMQ to
Elasticsearch and can then be graphed in Kibana.



Sounds much like what our development team has worked on lately. A lot
of work has been done with Radiator logging recently.



We only struggle with Radiators' logging in one place: the global
logfile contains log messages from e.g. Hooks which are hard to
impossible to link to a specific request.
I'm in the process of getting more Radiator logs into Elasticsearch and
I'll look into if the Handler Identifier can be logged there as well.



As Alan mentioned, there's support in patches for linking/tracking
requests that are related to each other. When a request is received, a
tracing id is assigned to it. This id is then available for logging and
can be logged, for example, as a JSON attribute for log and
authentication log. See LogFormat.pm for an example.

It's also possible to use the Class attribute to bind authentication
with the subsequent accounting messages. For example, if the tracing id
is logged in the authentication log, you can use it later to view all
the log and accounting information related to that id. This will show
how the authentication and accounting was processed and what accounting
records were created for that particular session.

Binding with State is also supported. This allows tracing EAP
authentication sessions and other multi round authentications that use
State.

If you use the default log file format instead of e.g., JSON, you can
configure the tracing id to be appended in front of each line that is
logged into the log file. This allows using grep to quickly see all
lines that are related to a request.

This is still ongoing work, but the above should summarise what's been
done so far.

Any thoughts and ideas are welcome. I can certainly tell more about the
subject, but I tried to keep this message short instead of going into
full details immediately. The patches download page also has the list of
what's been added recently.

Thanks,
Heikki





*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Heikki Vatiainen]

On 03/24/2016 01:18 PM, Hartmaier Alexander wrote:

> If you already calculate the response time can you please also expose it
> via a special placeholder character?

In the current patches there's the possibility to log RecvTime and
RecvTimeMicros which are the second and microsecond of the time when the
request was received. These are variables stamped in the current request
and with the patches you can do %{ReplyVar:RecvTime} to e.g., log them.

What you could do is to log these two variables and the current time and
let the log processing system do the math.

Currently the response time calculation happens just before the reply is
sent, so it's not available earlier, for example, for authentication
logging.

> I'd add this value to the AuthLog which goes via RabbitMQ to
> Elasticsearch and can then be graphed in Kibana.

Sounds much like what our development team has worked on lately. A lot
of work has been done with Radiator logging recently.

> We only struggle with Radiators' logging in one place: the global
> logfile contains log messages from e.g. Hooks which are hard to
> impossible to link to a specific request.
> I'm in the process of getting more Radiator logs into Elasticsearch and
> I'll look into if the Handler Identifier can be logged there as well.

As Alan mentioned, there's support in patches for linking/tracking
requests that are related to each other. When a request is received, a
tracing id is assigned to it. This id is then available for logging and
can be logged, for example, as a JSON attribute for log and
authentication log. See LogFormat.pm for an example.

It's also possible to use the Class attribute to bind authentication
with the subsequent accounting messages. For example, if the tracing id
is logged in the authentication log, you can use it later to view all
the log and accounting information related to that id. This will show
how the authentication and accounting was processed and what accounting
records were created for that particular session.

Binding with State is also supported. This allows tracing EAP
authentication sessions and other multi round authentications that use
State.

If you use the default log file format instead of e.g., JSON, you can
configure the tracing id to be appended in front of each line that is
logged into the log file. This allows using grep to quickly see all
lines that are related to a request.

This is still ongoing work, but the above should summarise what's been
done so far.

Any thoughts and ideas are welcome. I can certainly tell more about the
subject, but I tried to keep this message short instead of going into
full details immediately. The patches download page also has the list of
what's been added recently.

Thanks,
Heikki

-- 
Heikki Vatiainen 

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, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Alan Buxey]

I believe that the latest 4.16 patchsets allow all packets related to a 
particular authentication to be linked/tracked - you might find that to be 
useful

alan___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Hartmaier Alexander]

Hi,
that's neat!
If you already calculate the response time can you please also expose it
via a special placeholder character?

I'd add this value to the AuthLog which goes via RabbitMQ to
Elasticsearch and can then be graphed in Kibana.

We only struggle with Radiators' logging in one place: the global
logfile contains log messages from e.g. Hooks which are hard to
impossible to link to a specific request.
I'm in the process of getting more Radiator logs into Elasticsearch and
I'll look into if the Handler Identifier can be logged there as well.

Thanks, Alex

On 2016-03-24 08:27, Heikki Vatiainen wrote:
> On 24.3.2016 0.28, Hugh Irvine wrote:
>
>> Otherwise you can add your own custom time attributes in the current
>> request packet and post-process the logs to derive the deltas.
> Maybe this recent addition to 4.16 patches would be helpful too?
>
> Added a new global configuration parameter:
>
> ResponseTimeThreshold 10
>
> The value is a millisecond threshold for Radiator's response time. If
> the respose time is exceeded, a warning will be loggged.
>
> Here's an example of what it logs:
>
> Tue Mar 15 16:47:41 2016 577739: WARNING: Response time 16.804 ms for
> Access-Request id 236 exceeded 3 ms. (User: 'mikem', Client: 'DEFAULT'
> (default-client), Handler: '' (handler-identifier), Last AuthBy: 'FILE'
> (authby-identifier))
>
> Currently this is a global setting that's not turned on by default.
>
> Alex, you mentioned about logging each request with the processing time.
> Which logfile this should go into?
>
> There's work underway to log just the messages Radiator sends and
> receives. This is separate from the current logging and is more like
> what AuthLog does. What AuthLog logs are the successful and failed
> authentications. The message log will log all messages. The log format
> is configurable. At least text (similar to like trace 5 packet dump),
> pcapng and JSON will be supported.
>
> Thanks,
> Heikki
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Heikki Vatiainen]

On 24.3.2016 0.28, Hugh Irvine wrote:

> Otherwise you can add your own custom time attributes in the current
> request packet and post-process the logs to derive the deltas.

Maybe this recent addition to 4.16 patches would be helpful too?

Added a new global configuration parameter:

   ResponseTimeThreshold 10

The value is a millisecond threshold for Radiator's response time. If 
the respose time is exceeded, a warning will be loggged.

Here's an example of what it logs:

Tue Mar 15 16:47:41 2016 577739: WARNING: Response time 16.804 ms for 
Access-Request id 236 exceeded 3 ms. (User: 'mikem', Client: 'DEFAULT' 
(default-client), Handler: '' (handler-identifier), Last AuthBy: 'FILE' 
(authby-identifier))

Currently this is a global setting that's not turned on by default.

Alex, you mentioned about logging each request with the processing time. 
Which logfile this should go into?

There's work underway to log just the messages Radiator sends and 
receives. This is separate from the current logging and is more like 
what AuthLog does. What AuthLog logs are the successful and failed 
authentications. The message log will log all messages. The log format 
is configurable. At least text (similar to like trace 5 packet dump), 
pcapng and JSON will be supported.

Thanks,
Heikki

-- 
Heikki Vatiainen 

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, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Hugh Irvine]

Hi Alex -

I may have misunderstood your original question - %s is only the offset in the 
current second.

For what you want to do you should probably be using “LogMicroseconds” global 
parameter (requires “Time-Hires” from CPAN).

Otherwise you can add your own custom time attributes in the current request 
packet and post-process the logs to derive the deltas.

The AuthBy INTERNAL clause is very handy for this sort of thing if you add them 
into your processing sequence at the relevant places.

regards

Hugh


> On 23 Mar 2016, at 21:03, Hartmaier Alexander 
>  wrote:
> 
> Hi Hugh,
> is that a microsecond counter starting when the request is received?
> Imho the wording is confusing, will it wrap around when the request takes 
> more than one second?
> How would I log the microseconds as integer for requests that take longer 
> than one second?
> 
> Thanks, Alex
> 
> On 2016-03-23 10:33, Hugh Irvine wrote:
>> Hello Alex -
>> 
>> %s is the number of microseconds in the current second.
>> 
>> From section 5.2 of the Radiator 4.16 reference manual (“doc/ref.pdf”):
>> 
>>  %s  Microseconds in the current second
>> 
>> Note that the RADIUS protocol only defines times in seconds.
>> 
>> regards
>> 
>> Hugh
>> 
>> 
>>> On 23 Mar 2016, at 19:44, Hartmaier Alexander 
>>>  wrote:
>>> 
>>> Hi,
>>> I'd like to add the time it took to craft a response for each request to
>>> the logs.
>>> In the reference manual I only found %E which is 'The elapsed time in
>>> seconds since the packet was received. Can be used to log
>>> processing time for proxied packets etc.'.
>>> For this logging I'd need at least milli- or better microseconds.
>>> Did I overlook a placeholder for those or do they currently not exist?
>>> 
>>> How do you guys monitor response time to prevent clients marking a
>>> server as unresponsive because it takes it too long to send a response,
>>> most of the time because of a backend like LDAP, SQL database or proxied
>>> radius server being slow?
>>> 
>>> Thanks, Alex
>>> 
>>> 
>>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>>> T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
>>> Handelsgericht Wien, FN 79340b
>>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>>> Notice: This e-mail contains information that is confidential and may be 
>>> privileged.
>>> If you are not the intended recipient, please notify the sender and then
>>> delete this e-mail immediately.
>>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>>> ___
>>> radiator mailing list
>>> radiator@open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>> 
>> --
>> 
>> Hugh Irvine
>> h...@open.com.au
>> 
>> 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, EAP, TLS,
>> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
>> DIAMETER, SIM, etc.
>> Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
>> 
> 


--

Hugh Irvine
h...@open.com.au

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, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER, SIM, etc. 
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Hugh Irvine]

Hello Alex -

%s is the number of microseconds in the current second.

From section 5.2 of the Radiator 4.16 reference manual (“doc/ref.pdf”):

%s  Microseconds in the current second

Note that the RADIUS protocol only defines times in seconds.

regards

Hugh


> On 23 Mar 2016, at 19:44, Hartmaier Alexander 
>  wrote:
> 
> Hi,
> I'd like to add the time it took to craft a response for each request to
> the logs.
> In the reference manual I only found %E which is 'The elapsed time in
> seconds since the packet was received. Can be used to log
> processing time for proxied packets etc.'.
> For this logging I'd need at least milli- or better microseconds.
> Did I overlook a placeholder for those or do they currently not exist?
> 
> How do you guys monitor response time to prevent clients marking a
> server as unresponsive because it takes it too long to send a response,
> most of the time because of a backend like LDAP, SQL database or proxied
> radius server being slow?
> 
> Thanks, Alex
> 
> 
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
> Handelsgericht Wien, FN 79340b
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> Notice: This e-mail contains information that is confidential and may be 
> privileged.
> If you are not the intended recipient, please notify the sender and then
> delete this e-mail immediately.
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
h...@open.com.au

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, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER, SIM, etc. 
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance tuning

[Jared Watkins]

Replying to my own comment.. just so others could maybe benefit.  After wasting 
many hours trying to figure this out.. I finally did this morning.  My problem 
was that I was sending multiple streams of records from one IP to the same 
Radiator server and it was discarding most of them because of overlapping 
sequence numbers.  The network buffer *may* have been part of the original 
problem.. but subsequent attempts to load historical data through the same 
servers I was loading live data was not working as expected. 




On Feb 9, 2012, at 11:07 AM, Jared Watkins wrote:

> Hello.. 
> 
> I'm attempting to load some old cdr accounting data into my dev environment 
> through Radiator and I'm seeing a problem with dropped records.  I saw the 
> note in the doc about increasing the SocketQueueLength and I've done that 
> both in the Radiator config and in the OS... taking it from 128k to 12M. 
> (overkill?) but even with that... every time I reload the same days data from 
> disk.. I'm getting more and more records into the DB for that day. It's not a 
> big difference.. maybe 200 more recs out of 18k each time I resend the data. 
> I'm using the unique recordid as the primary DB key to avoid duplicate 
> entries.   I'm not seeing any errors or timeouts on the client side.. which 
> tells me the packets are being acknowledged as received and I see a 
> continuous stream of packets to and from the client.. but when tailing a 
> debug log from radiator where I should see one log entry for every record.. I 
> see periodic pauses in the log... sometimes of a few seconds. 
> 
> Of course this isn't a normal level of activity... this is me blasting the 
> server from cdr files stored on disk. Any insight on what else I might try 
> here? 
> 
> Thanks,
> J
> 
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: (RADIATOR) Performance on SUN Solaris 2.6 with two CPUs

[Hugh Irvine]

Hello Ronald -

I will need to understand much more about else is going on in your 
configuration file, and what else is going on with your system.

A configuration such as you describe should be able to process at least 
several hundred radius requests per second.

The most obvious thing to check is the logging that Radiator is doing 
for both event logging and for accounting logging.

How many requests per second is the system doing overall?

Please send me some copies of "vmstat", "iostat", etc. so I can see 
what is happening.

BTW - the latest version of Radiator is 3.4.

regards

Hugh


On Monday, Dec 2, 2002, at 20:36 Australia/Melbourne, Looijestijn, 
Ronald wrote:

Hi all,

I have a question about the performance of radiator running on a Sun 
Solaris
2.6 system with two CPUs.

We are using radiator 2.19 as a proxy server. Within this 
configuration we
do not use any Sessiondatabase or SQL functionality.
We just proxy the accounting en authentication requests to other radius
servers.
The accounting and authentication requests are handled with seperate
processes. (two radiusd processes on the proxy server)

The proxy server has a maximum cpu usage of 56% during the day. 
(including
IO-wait, user and system time).
Now we are experiencing UdpInOverflows every day.

It seems that radiator can not take the full usage of the capacity of 
the
SUN server.

Can anyone explain this behavior ? How can we configure Radiator or 
Solaris
to use the full capacity of the two CPUs ?
Are there more people experiencing this probleem ?

Thanks.

Ronald

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

(RADIATOR) Re: Radiator: Performance issue

[Hugh Irvine]

Hello Jaafar -

Given the sizes of your /etc/paswd and /etc/shadow files, I am not 
surprised that Radiator is taking so long to start up. You should really 
be using an SQL database for such large user populations.

regards

Hugh


On Tuesday, September 3, 2002, at 02:14 PM, Jaafar Bin Sarim wrote:

> Hello Hugh
>
> I'm running 5 instances of radiusd operating in one server 256M RAM
> and CPU 200MHz Ultra sparc1.
>
> Each of the 5 instances takes this much time to start as shown below:
>
> #/var/run 539$ time rad-roamin start
>
> real0m53.145s
> user0m44.750s
> sys 0m1.800s
>
> The sizes of /etc/passwd and /etc/shadow in the server are as follows:
> -rw-r--r--   1 root staff21215436 Sep  3 11:37 /etc/passwd
> -r   1 root staff10251013 Sep  3 11:37 /etc/shadow
>
> We're running on Radiator version 3.1
>
> We're updating our /etc/passwd and /etc/shadow every hour and the 5
> radius instances seem to be caching every hour as well.
> This result in unavailability of the 5 radius instances.
>
> Are there any tips to improve performance or avoid any recaching 
> overlaps.
>
> Thank you.
>
>
> Best Regards
> Jaafar Sarim
> SingNet
>
>
>
>

--
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 [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Re: (RADIATOR) performance on SPARC III?

[Hugh Irvine]

Hello Swee-Chuan Khoo -

Nice to hear from you again - hope you are well?

In answer to your question, the configuration you describe below will 
undoubtedly be rate limited by the LDAP server and the accounting 
server.

In any case, I did some tests myself last week on a SUN Enterprise 
250, with Radiator, radpwtst and mysql all running on the same box 
and I got around 90 requests per second. Your target of 150/sec 
sounds achievable, but as I say, you will likely find that your 
limits are imposed by the LDAP server and the accounting server.

When you get some numbers from your testing I would be interested to see them.

BTW - you should run Radiator with the trace -1 option, and radpwtst 
with the -notrace option when doing testing.


best regards

Hugh


At 10:22 +0800 01/7/5, Swee-Chuan Khoo wrote:
>hi,
>
>i am helping a customer evaluate running radiator on Sun SPARC III
>based server.
>
>possibly a 4-way server with 4GB RAM. LDAP authentication
>with LDAP server on another server. accounting is going to another
>server as well.
>
>any number out there as in how many authentication/sec it can achieve?
>i need to look for a solution to scale to 150/sec.
>
>thanx.
>
>--
>Swee-Chuan Khoo
>Technical Consultant SunPS
>
>"To ask permission is to seek denial"
>===
>Archive at http://www.open.com.au/archives/radiator/
>Announcements on [EMAIL PROTECTED]
>To unsubscribe, email '[EMAIL PROTECTED]' with
>'unsubscribe radiator' in the body of the message.

-- 

NB: I am travelling this week, so there may be delays in our correspondence.

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Re: (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, [EMAIL PROTECTED] 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:[EMAIL PROTECTED]]
> Enviado el: miércoles 23 de mayo de 2001 10:25
> Para: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> 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, [EMAIL PROTECTED] 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:[EMAIL PROTECTED]]
> > Enviado el: viernes 18 de mayo de 2001 11:00
> > Para: [EMAIL PROTECTED]
> > 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.
> >
> >

RE: (RADIATOR) performance question

[julio . prada]

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:[EMAIL PROTECTED]]
Enviado el: miércoles 23 de mayo de 2001 10:25
Para: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
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, [EMAIL PROTECTED] 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:[EMAIL PROTECTED]]
> Enviado el: viernes 18 de mayo de 2001 11:00
> Para: [EMAIL PROTECTED]
> 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 [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.open.com.au/archives/radiator/
> Announcements on [EMAIL PROTECTED]
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body 

Re: (RADIATOR) performance question

[Hugh Irvine]

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, [EMAIL PROTECTED] 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:[EMAIL PROTECTED]]
> Enviado el: viernes 18 de mayo de 2001 11:00
> Para: [EMAIL PROTECTED]
> 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 [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.open.com.au/archives/radiator/
> Announcements on [EMAIL PROTECTED]
> To unsubscribe, email '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

RE: (RADIATOR) performance question

[julio . prada]

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:[EMAIL PROTECTED]]
Enviado el: viernes 18 de mayo de 2001 11:00
Para: [EMAIL PROTECTED]
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 [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.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Re: (RADIATOR) performance issue

[Hugh Irvine]

Hello Mariano -

My general approach in creating configuration files is to do as much as 
possible in one single file using GlobalVar's that are set at run time on the 
command line to create different instances. 

As regards something like AuthLog FILE, as it will never be called in an 
accounting-only instance, it will not cause any performance problems at all.

regards

Hugh


On Tuesday 08 May 2001 06:44, Mariano Absatz wrote:
> El 3 May 2001, a las 11:07, Hugh Irvine escribió:
> > Hello Mariano -
> >
> > On Thursday 03 May 2001 06:15, Mariano Absatz wrote:
> > > Hi... on my delayed reading of the list I found this:
> > >
> > > El 18 Apr 2001, a las 9:45, Hugh Irvine escribió:
> > > > Hello Andy -
> > > >
> > > > The session database will be accessed by both authentication (to
> > > > delete and to check limits) and accounting (to insert and delete).
> > >
> > > 
> > >
> > > So... I have different instances of Radiator for accounting and
> > > authentication, then BOTH have to have the  clause?
> > > And should they be identical?
> >
> > Yes. This is the same situation as having multiple machines running
> > Radiator - they all need to share the same session database (if coherency
> > among them is an issue).
> >
> > > On re-reading the "Performance and Tunning" section in the manual
> > > (http://www.open.com.au/radiator/ref.html#pgfId=406539), I find a good
> > > list of hints, but most of them are sometimes not very usefull when you
> > > DO have to do some strange things... anyway, since I saw it many times
> > > in the list, the separation between an Authentication server and an
> > > Accounting server in different instances even when it is in the same
> > > machine, seems to be a no-lose proposition, since you are losing no
> > > functionality at all (I think) and you don't have to buy extra hardware
> > > (it's easy to say "see, boss, I need 4 or 5 more Sun Netras T1 to
> > > improve radius speed" only to hear him say "gee, why don't you do it
> > > with that Sparc I that no one is using now?").
> > >
> > > Since I see this so often said in the list, it might get a subsection
> > > with some configuration tips for this, like, "you have to put this kind
> > > of sections on the auth config, those sections in the acct config and
> > > this bunch in both... maybe you should use "Include common.cfg" for
> > > these last ones...
> > >
> > > Put it in the wishlist for the next release (2.18.2? 2.19? please don't
> > > do anything like naming it "Radiator 20" -à la Solaris- or "Radiator
> > > 2001" or "Radiator NE (Nonsense Edition)" -à la MS- :-)
> >
> > I have been thinking about adding some more complex configuration files
> > to the goodies section and I can see that the manual could contain some
> > more detail. Thanks for the suggestion.
>
> On a general way, I would like to be as "clean" as possible when writing
> my config files and repeat as little as possible.
>
> I am writing 3 config files:
>
> 1)radius-auth.cfg
> 2)radius-acct.cfg
> 3)radius-common.cfg
>
> first thing 1) & 2) do is include 3), which has the common configuration.
>
> 1) & 2) obviously have the corresponding authport & acctport, and
> SNMPAgent in different ports.
>
> >From a maintainance point of view, I woul like to have as much as
>
> possible in 3), from what you say in your message, for instance
>  must be there.
>
> Now, if I put EVERYTHING except authport, acctport and SNMPAgent in 3),
> will that have a performance penalty?
>
> Obviously, it will be slower at startup, but that is not an issue, since,
> once it's working, I don't expect to shut it down except for programmed
> upgrades or the like...
>
> Otherwise, is there a rule of thumb as to what goes where? I could start
> putting everything in 3) and then migrating to the obvious choice where
> there is one and see how I'm doing, but I think that will take a lot of
> trial and error...
>
> For instance  could go only in 1) (I think), but would it
> be "bad" if I put it in 3)?
>
> TIA

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

[Mariano Absatz]

El 3 May 2001, a las 11:07, Hugh Irvine escribió:

> 
> Hello Mariano -
> 
> On Thursday 03 May 2001 06:15, Mariano Absatz wrote:
> > Hi... on my delayed reading of the list I found this:
> >
> > El 18 Apr 2001, a las 9:45, Hugh Irvine escribió:
> > > Hello Andy -
> > >
> > > The session database will be accessed by both authentication (to delete
> > > and to check limits) and accounting (to insert and delete).
> >
> > 
> >
> > So... I have different instances of Radiator for accounting and
> > authentication, then BOTH have to have the  clause? And
> > should they be identical?
> >
> 
> Yes. This is the same situation as having multiple machines running Radiator 
> - they all need to share the same session database (if coherency among them 
> is an issue).
> 
> > On re-reading the "Performance and Tunning" section in the manual
> > (http://www.open.com.au/radiator/ref.html#pgfId=406539), I find a good
> > list of hints, but most of them are sometimes not very usefull when you
> > DO have to do some strange things... anyway, since I saw it many times in
> > the list, the separation between an Authentication server and an
> > Accounting server in different instances even when it is in the same
> > machine, seems to be a no-lose proposition, since you are losing no
> > functionality at all (I think) and you don't have to buy extra hardware
> > (it's easy to say "see, boss, I need 4 or 5 more Sun Netras T1 to improve
> > radius speed" only to hear him say "gee, why don't you do it with that
> > Sparc I that no one is using now?").
> >
> > Since I see this so often said in the list, it might get a subsection
> > with some configuration tips for this, like, "you have to put this kind
> > of sections on the auth config, those sections in the acct config and
> > this bunch in both... maybe you should use "Include common.cfg" for these
> > last ones...
> >
> > Put it in the wishlist for the next release (2.18.2? 2.19? please don't
> > do anything like naming it "Radiator 20" -à la Solaris- or "Radiator
> > 2001" or "Radiator NE (Nonsense Edition)" -à la MS- :-)
> 
> I have been thinking about adding some more complex configuration files to 
> the goodies section and I can see that the manual could contain some more 
> detail. Thanks for the suggestion.

On a general way, I would like to be as "clean" as possible when writing 
my config files and repeat as little as possible.

I am writing 3 config files:

1)radius-auth.cfg
2)radius-acct.cfg
3)radius-common.cfg

first thing 1) & 2) do is include 3), which has the common configuration.

1) & 2) obviously have the corresponding authport & acctport, and 
SNMPAgent in different ports.

>From a maintainance point of view, I woul like to have as much as 
possible in 3), from what you say in your message, for instance 
 must be there.

Now, if I put EVERYTHING except authport, acctport and SNMPAgent in 3), 
will that have a performance penalty?

Obviously, it will be slower at startup, but that is not an issue, since, 
once it's working, I don't expect to shut it down except for programmed 
upgrades or the like...

Otherwise, is there a rule of thumb as to what goes where? I could start 
putting everything in 3) and then migrating to the obvious choice where 
there is one and see how I'm doing, but I think that will take a lot of 
trial and error... 

For instance  could go only in 1) (I think), but would it 
be "bad" if I put it in 3)?

TIA
===
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 issue

[Hugh Irvine]

Hello Mariano -

We have no plans to change the name Radiator (thank goodness I hear you say)!

BTW - in regards to your comment about the size of the Radiator executable, 
note that Perl only loads the modules that are needed at run time. In other 
words, even though Radiator is delivered with *many* AuthBy modules - only 
those that are specified in the configuration file are actually loaded into 
memory. It will be the same with the Diameter support.

regards

Hugh


On Thursday 03 May 2001 22:57, Mariano Absatz wrote:
> El 3 May 2001, a las 11:07, Hugh Irvine escribió:
> > Hello Mariano -
> >
> > On Thursday 03 May 2001 06:15, Mariano Absatz wrote:
> > > Hi... on my delayed reading of the list I found this:
> > >
> > > El 18 Apr 2001, a las 9:45, Hugh Irvine escribió:
> > > > Hello Andy -
> > > >
> > > > The session database will be accessed by both authentication (to
> > > > delete and to check limits) and accounting (to insert and delete).
> > >
> > > 
> > >
> > > So... I have different instances of Radiator for accounting and
> > > authentication, then BOTH have to have the  clause?
> > > And should they be identical?
> >
> > Yes. This is the same situation as having multiple machines running
> > Radiator - they all need to share the same session database (if coherency
> > among them is an issue).
>
> OK... I'll put this in my include file, then...
>
>
> 
>
> > BTW - I think the next major release of Radiator will be Radiator-3.0,
> > which will include support for the next generation "Diameter" protocol.
> >
> > http://www.ietf.org/html.charters/aaa-charter.html
>
> Good... I've been reading the diameter i-d's... it's kind of a little
> beast, it would be nice if you could configure Radiator 3.0 (please,
> don't call it Diameterator :-D ) without the diameter support, since I
> guess it will add really lots of code and (yet) I don't see a lot of
> market pressure (here in Argentina, at least) for most of it's features...

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

[Mariano Absatz]

El 3 May 2001, a las 11:07, Hugh Irvine escribió:

> 
> Hello Mariano -
> 
> On Thursday 03 May 2001 06:15, Mariano Absatz wrote:
> > Hi... on my delayed reading of the list I found this:
> >
> > El 18 Apr 2001, a las 9:45, Hugh Irvine escribió:
> > > Hello Andy -
> > >
> > > The session database will be accessed by both authentication (to delete
> > > and to check limits) and accounting (to insert and delete).
> >
> > 
> >
> > So... I have different instances of Radiator for accounting and
> > authentication, then BOTH have to have the  clause? And
> > should they be identical?
> >
> 
> Yes. This is the same situation as having multiple machines running Radiator 
> - they all need to share the same session database (if coherency among them 
> is an issue).
OK... I'll put this in my include file, then...

> 

> 
> BTW - I think the next major release of Radiator will be Radiator-3.0, which 
> will include support for the next generation "Diameter" protocol.
> 
>   http://www.ietf.org/html.charters/aaa-charter.html
Good... I've been reading the diameter i-d's... it's kind of a little 
beast, it would be nice if you could configure Radiator 3.0 (please, 
don't call it Diameterator :-D ) without the diameter support, since I 
guess it will add really lots of code and (yet) I don't see a lot of 
market pressure (here in Argentina, at least) for most of it's features...



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

[Hugh Irvine]

Hello Mariano -

On Thursday 03 May 2001 06:15, Mariano Absatz wrote:
> Hi... on my delayed reading of the list I found this:
>
> El 18 Apr 2001, a las 9:45, Hugh Irvine escribió:
> > Hello Andy -
> >
> > The session database will be accessed by both authentication (to delete
> > and to check limits) and accounting (to insert and delete).
>
> 
>
> So... I have different instances of Radiator for accounting and
> authentication, then BOTH have to have the  clause? And
> should they be identical?
>

Yes. This is the same situation as having multiple machines running Radiator 
- they all need to share the same session database (if coherency among them 
is an issue).

> On re-reading the "Performance and Tunning" section in the manual
> (http://www.open.com.au/radiator/ref.html#pgfId=406539), I find a good
> list of hints, but most of them are sometimes not very usefull when you
> DO have to do some strange things... anyway, since I saw it many times in
> the list, the separation between an Authentication server and an
> Accounting server in different instances even when it is in the same
> machine, seems to be a no-lose proposition, since you are losing no
> functionality at all (I think) and you don't have to buy extra hardware
> (it's easy to say "see, boss, I need 4 or 5 more Sun Netras T1 to improve
> radius speed" only to hear him say "gee, why don't you do it with that
> Sparc I that no one is using now?").
>
> Since I see this so often said in the list, it might get a subsection
> with some configuration tips for this, like, "you have to put this kind
> of sections on the auth config, those sections in the acct config and
> this bunch in both... maybe you should use "Include common.cfg" for these
> last ones...
>
> Put it in the wishlist for the next release (2.18.2? 2.19? please don't
> do anything like naming it "Radiator 20" -à la Solaris- or "Radiator
> 2001" or "Radiator NE (Nonsense Edition)" -à la MS- :-)

I have been thinking about adding some more complex configuration files to 
the goodies section and I can see that the manual could contain some more 
detail. Thanks for the suggestion.

BTW - I think the next major release of Radiator will be Radiator-3.0, which 
will include support for the next generation "Diameter" protocol.

http://www.ietf.org/html.charters/aaa-charter.html

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 issue

[Mariano Absatz]

Hi... on my delayed reading of the list I found this:

El 18 Apr 2001, a las 9:45, Hugh Irvine escribió:

> 
> Hello Andy -
> 
> The session database will be accessed by both authentication (to delete and 
> to check limits) and accounting (to insert and delete).
> 


So... I have different instances of Radiator for accounting and 
authentication, then BOTH have to have the  clause? And 
should they be identical?

On re-reading the "Performance and Tunning" section in the manual 
(http://www.open.com.au/radiator/ref.html#pgfId=406539), I find a good 
list of hints, but most of them are sometimes not very usefull when you 
DO have to do some strange things... anyway, since I saw it many times in 
the list, the separation between an Authentication server and an 
Accounting server in different instances even when it is in the same 
machine, seems to be a no-lose proposition, since you are losing no 
functionality at all (I think) and you don't have to buy extra hardware 
(it's easy to say "see, boss, I need 4 or 5 more Sun Netras T1 to improve 
radius speed" only to hear him say "gee, why don't you do it with that 
Sparc I that no one is using now?").

Since I see this so often said in the list, it might get a subsection 
with some configuration tips for this, like, "you have to put this kind 
of sections on the auth config, those sections in the acct config and 
this bunch in both... maybe you should use "Include common.cfg" for these 
last ones...

Put it in the wishlist for the next release (2.18.2? 2.19? please don't 
do anything like naming it "Radiator 20" -à la Solaris- or "Radiator 
2001" or "Radiator NE (Nonsense Edition)" -à la MS- :-)


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

[Andy De Petter]

That I don't understand.

How can the authentication radiusd access the session database, when it's
not configured -at all- in its configuration file?   Please mind, that I'm
running 1 radiusd for authentication, and 1 for accounting .. and I don't
have any  clause, in the authentication one..

-Andy

> -Original Message-
> From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Sent: woensdag 18 april 2001 1:45
> To: Andy De Petter; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: (RADIATOR) performance issue
>
>
>
> Hello Andy -
>
> The session database will be accessed by both authentication (to
> delete and
> to check limits) and accounting (to insert and delete).
>
> cheers
>
> Hugh
>
> On Wednesday 18 April 2001 00:19, Andy De Petter wrote:
> > > Your problem sounds familiar to us because at the beginning,
> we launched
> > > tests of 1000 authentication requests and the 40% were dropped.
> >
> > Were those 40% authentication or accounting?
> >
> > I'm running accounting & authentication on different daemons.. and the
> > session db is configured on the accounting daemon, so
> authentication here
> > is not affected, by any slowdown of the accounting daemon.
> >
> > -Andy
> >
> > --
> > "For nothing can seem foul to those that win."
> >   - Henry IV, Pt1, Act 5, Sc 1
> >
> > *** 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.
>
> --
> 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 issue

[Hugh Irvine]

Hello Andy -

The session database will be accessed by both authentication (to delete and 
to check limits) and accounting (to insert and delete).

cheers

Hugh

On Wednesday 18 April 2001 00:19, Andy De Petter wrote:
> > Your problem sounds familiar to us because at the beginning, we launched
> > tests of 1000 authentication requests and the 40% were dropped.
>
> Were those 40% authentication or accounting?
>
> I'm running accounting & authentication on different daemons.. and the
> session db is configured on the accounting daemon, so authentication here
> is not affected, by any slowdown of the accounting daemon.
>
> -Andy
>
> --
> "For nothing can seem foul to those that win."
>   - Henry IV, Pt1, Act 5, Sc 1
>
> *** 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.

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

[Hugh Irvine]

Hello Andy -

There has been some work done on the session database recently and Mike has 
added some indexing and a modified query for MySQL that includes a "limit 1" 
when searching for an address. 

You should upgrade to Radiator 2.18 (plus patches).

I have also copied Mike on this mail so he can give you the details.

cheers

Hugh


On Tuesday 17 April 2001 20:33, Andy De Petter wrote:
> Hello,
>
> I'm having a bit of a problem with the session database, on Radiator
> 2.17.1. I have 2 radius servers running, sharing a remote SQL database for
> all active sessions.  The authentication of clients, also happens through
> remote SQL databases, on different machines than the session db.
>
> Now, when the session database is enabled, I have a very high amount of UDP
> packets (mostly accounting) dropped, between the access servers, and the
> radius servers.  When disabling it, nearly no packets are dropped.   The
> session database, runs on a high-end Sun Enterprise server, with plenty of
> CPU and memory, and is dedicated to the session db (MySQL).  The load on
> the session db server, is nearly nothing, and the SQL server isn't showing
> any performance problems.  Also the load on the radius servers, isn't
> rising, after enabling the session db.
>
> At first sight, this doesn't really seem to be a network problem, as there
> is a direct dedicated line, between access servers, and radius servers.
>
> Something, that might be interesting aswell, is that the incoming/outgoing
> traffic multiplies by 5, when enabling the session database, and outgoing
> traffic is nearly half of incoming traffic while without the session
> database, in/outgoing traffic is approx. equal to eachother.
>
> I know this might sound a bit confusing, and might require you to read the
> problem a few times, before understanding it .. but it's really odd, and at
> the moment, I can't afford to enable the session db, due to the packetloss
> between access servers and radius servers in that case :-/
>
> -Andy
>
> --
> "For nothing can seem foul to those that win."
>   - Henry IV, Pt1, Act 5, Sc 1
>
> *** 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.

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

[julio . prada]

In auth a 40%. And in acct. around 20% more or less.

jules.

-Mensaje original-
De: Andy De Petter [mailto:[EMAIL PROTECTED]]
Enviado el: martes 17 de abril de 2001 16:20
Para: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Asunto: RE: (RADIATOR) performance issue



>
> Your problem sounds familiar to us because at the beginning, we launched
> tests of 1000 authentication requests and the 40% were dropped.
>

Were those 40% authentication or accounting?

I'm running accounting & authentication on different daemons.. and the
session db is configured on the accounting daemon, so authentication here is
not affected, by any slowdown of the accounting daemon.

-Andy

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

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

[Andy De Petter]

>
> Your problem sounds familiar to us because at the beginning, we launched
> tests of 1000 authentication requests and the 40% were dropped.
>

Were those 40% authentication or accounting?

I'm running accounting & authentication on different daemons.. and the
session db is configured on the accounting daemon, so authentication here is
not affected, by any slowdown of the accounting daemon.

-Andy

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

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

[julio . prada]

hello Andy,

Since changes in radiator 2.17 (I think Mike improved the SQL modules)
sessions databases works secure but a litle slow than before. I mean that
(for example) IP "racing" in Authby Dynaddress works fine (better than 2.16
!) but some requests are dropped (probably due to the timeout).

In the performance tests we noticed that a tunning in your DBM can resolve
these problems of dropped requests. In our case, we changed from MySQL to
Oracle and now we are tunning Oracle. Today our performance is about 50 req.
per second (without dropped packets).

Your problem sounds familiar to us because at the beginning, we launched
tests of 1000 authentication requests and the 40% were dropped.

Try make some tunning on you MySQL database, and put some sniffers to see
the number of requests sent and received in both cases (with/without session
db).

regards,
jules

-Mensaje original-
De: Andy De Petter [mailto:[EMAIL PROTECTED]]
Enviado el: martes 17 de abril de 2001 12:34
Para: Radiator Mailing
Asunto: (RADIATOR) performance issue



Hello,

I'm having a bit of a problem with the session database, on Radiator 2.17.1.
I have 2 radius servers running, sharing a remote SQL database for all
active sessions.  The authentication of clients, also happens through remote
SQL databases, on different machines than the session db.

Now, when the session database is enabled, I have a very high amount of UDP
packets (mostly accounting) dropped, between the access servers, and the
radius servers.  When disabling it, nearly no packets are dropped.   The
session database, runs on a high-end Sun Enterprise server, with plenty of
CPU and memory, and is dedicated to the session db (MySQL).  The load on the
session db server, is nearly nothing, and the SQL server isn't showing any
performance problems.  Also the load on the radius servers, isn't rising,
after enabling the session db.

At first sight, this doesn't really seem to be a network problem, as there
is a direct dedicated line, between access servers, and radius servers.

Something, that might be interesting aswell, is that the incoming/outgoing
traffic multiplies by 5, when enabling the session database, and outgoing
traffic is nearly half of incoming traffic while without the session
database, in/outgoing traffic is approx. equal to eachother.

I know this might sound a bit confusing, and might require you to read the
problem a few times, before understanding it .. but it's really odd, and at
the moment, I can't afford to enable the session db, due to the packetloss
between access servers and radius servers in that case :-/

-Andy

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

*** 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.
** 
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: IMPORTANT - Re: (RADIATOR) Performance with RADIATOR

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

Re: (RADIATOR) Performance Problem-configuration

[Hugh Irvine]

Hello Ray -

Could you please send me your userid and the company name of the registered
purchaser of this copy of Radiator?

thanks

Hugh

On Thu, 19 Oct 2000, [EMAIL PROTECTED] wrote:
> hi, anyone can give a hand?
> 
> I use radiator as a roaming center, but it seems that when the requests up
> to a limit, the response time is too long.
> 
> the "radius.cfg" file is below, it's a simple one. pls have a look, and tell
> me there is someplace misconfigured.
> 
> + === radius.cfg
> === +
> ..
> AAuthPort1645
> 
> AcctPort1646
> 
> LogDir  /var/radiator/log
> 
> DbDir   /usr/local/radiator/raddb
> 
> LogFile %L/radius.log
> 
> DictionaryFile %D/dictionary.cisco
> 
> SocketQueueLength 1000
> 
> 
>PreHandlerHook file:"%D/hooks/AddNewAttr.pl"
> Secret  cisco
> DupInterval 10
> 
> 
> 
> 
> Host 192.168.1.8
> AuthPort 1812
> AcctPort 1813
> Secret  cisco
> RetryTimeout 15
> Retries 0
> 
> 
> +  End of radius.cfg
> ==+
> 
> + === file:"%D/hooks/AddNewAttr.pl"
> == +
> sub
> {
> 
> my $p = ${$_[0]};
> my $user_name;
> $user_name = $p->get_attr('User-Name');
> if (length($user_name) < 13)
> {
> $p->add_attr('NewAttr', '1');
> }
> return;
> }
> + == End of file:"%D/hooks/AddNewAttr.pl"
> == +
> 
> # The requests(auth and accouting) is more than 60/second at peak time
> 
> Need Your Kindly Help, thanks in advance.
> 
> Ray
> 
> ===
> 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.
-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, 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 Monitoring

[Darwin A. Bawasanta]

Hello Elias, what we did on our end is monitor Radiator's performance
using MRTG graphs.  we are only monitoring total requests against
accepts, rejects, dropped, bad authenticators, and accounting.

one nice thing about Radiator is that you can define SNMP comunity
trings and even a separate SNMP port in case you are using the standard
SNMP port for your server (hardware, disks, memory, traffic) performance
monitoring.
  
i can share my MRTG config if you are interested.


Hugh Irvine wrote:
> 
> Hello Elias -
> 
> On Mon, 25 Sep 2000, Elias wrote:
> >
> > Hi,
> >
> > I'm trying to monitor the performance of Radiator. Is there any way to
> check the number of users authenticated per day and the number of
> authentication failures? Also, how can I record the total response time for
> each authentication request?
> 
> The easiest way to check the number of authentications per day is simply to
> count the number of accounting records (starts or stops) in your database on a
> daily basis. Also if you set logging to the database, you can do the same thing
> with failure messages (or you can just parse the log file).
> 
> As to measuring total response time for each authentication, that is a bit
> harder, as Radiator will only see the access request after the modem handshake
> and the initial PPP sequence. Some NAS equipment will report the amount of time
> taken to set up a call in the accounting records, but most do not. Normally
> Radiator does not log successful authentications unless it is running with
> Trace 4, but I would not recommend this in a production environment. There are
> some statistics maintained by Radiator that you can query via a radius status
> server request or via SNMP. The only other option might be to check your
> database statistics for response times to certain queries.
> 
> hth
> 
> Hugh
> 
> ps - how is everyone at Telecom Malaysia? Please say hello on my behalf.
> 
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
> Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, 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.

-- 
  __   
OO- `. Darwin A. Bawasanta  [EMAIL PROTECTED] pgp-id: 0x367CADAC
*  ||| Systems Development Manager SKYCablenet, Inc.
L_(_/  Ofc: +63 32 253-6677 Mobile: +63 917 486-5033
  |||==
 ((_|  "If the facts don't fit the theory, change the facts."

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

[Hugh Irvine]

Hello Elias -

On Mon, 25 Sep 2000, Elias wrote:
> 
> Hi,
> 
> I'm trying to monitor the performance of Radiator. Is there any way to 
check the number of users authenticated per day and the number of
authentication failures? Also, how can I record the total response time for
each authentication request?

The easiest way to check the number of authentications per day is simply to
count the number of accounting records (starts or stops) in your database on a
daily basis. Also if you set logging to the database, you can do the same thing
with failure messages (or you can just parse the log file).

As to measuring total response time for each authentication, that is a bit
harder, as Radiator will only see the access request after the modem handshake
and the initial PPP sequence. Some NAS equipment will report the amount of time
taken to set up a call in the accounting records, but most do not. Normally
Radiator does not log successful authentications unless it is running with
Trace 4, but I would not recommend this in a production environment. There are
some statistics maintained by Radiator that you can query via a radius status
server request or via SNMP. The only other option might be to check your
database statistics for response times to certain queries.

hth

Hugh

ps - how is everyone at Telecom Malaysia? Please say hello on my behalf.


-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, 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 on different plattforms

[Brian Keefe]

Roland,

We found Linux was 3x faster than Solaris, apparently due to CPU clock
speeds.
This test did not involve database calls or accounting. It had a tiny user
database.
So this test basically measured just the performance of Radiator
authentication.
The clients were pounding it from remote machines.

However, we did not test Solaris x86 or Linux on SPARC (if this port
exists),
and so cannot be sure clock speed solely explains the difference.
It could be the OS or the perl impl make a difference.

It may also be the dual processors on the Linux box made a difference.
That is, although radiator is not threaded, the second processor may have
been used for i/o, ipc, etc.

We did not test NT.

We are deploying on Solaris rather than Linux only because our colo site
does not yet provide full support for Linux.
But our plans are to use Linux as soon as possible due to the performance
differences and costs.

We find administration of Linux easier than Solaris for the software we use
on Linux for the radius servers.
But this is only radiator and perl in our case.

-- Brian


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Hugh Irvine
Sent: Friday, May 12, 2000 12:29 AM
To: Roland Axelsson; [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Performance on different plattforms



Hello Roland -

On Fri, 12 May 2000, Roland Axelsson wrote:
> Hi everyone,
>
> We need a radius solution in our company and I've tested the Radiator
> for a while on a Linux server. It runs well and seem to be configurable
> in many ways so we have decided to use it.
> The staff who are going to run those servers don't think they know
> enough about Linux though, so they want to run it on either NT or
> Solaris.
> Later on we hope to have ten thousands and more connects and we are
> planning to cluster those servers.  They are going to authorize and log
> sessions on a clustered Oracle database.
> So, what do you think about the performance issue.
> How big is the difference in performance between Linux and NT on the
> same hardware.
> How big difference between NT and Sun Solaris on similar cost hardware?
> Where is the bottleneck? Memory / CPU?
>
> Hope you guys with experience of this kind of systems will answer...
> I know Linux is the best price / performance, but I don't have time to
> run and support those servers myself.
> If you think Linux is outstanding, I can maybe push those guys to learn
> it.
>

We have customers running all three of these environments, and all perform
well. We have done some comparative performance testing and there are some
numbers in section 23.0 of the Radiator reference manual. There are also
some
descriptions of a few customer installations at the following URL:

http://www.open.com.au/radiator/examples.html

On this same topic we are still looking to add more examples to this page so
if
anyone else would like to contribute a description of their system, please
send
it directly to me (with a note stating if you want it to be anonymous or
not).

regards

Hugh

--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, 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.


===
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 on different plattforms

[Hugh Irvine]

Hello Roland -

On Fri, 12 May 2000, Roland Axelsson wrote:
> Hi everyone,
> 
> We need a radius solution in our company and I've tested the Radiator
> for a while on a Linux server. It runs well and seem to be configurable
> in many ways so we have decided to use it.
> The staff who are going to run those servers don't think they know
> enough about Linux though, so they want to run it on either NT or
> Solaris.
> Later on we hope to have ten thousands and more connects and we are
> planning to cluster those servers.  They are going to authorize and log
> sessions on a clustered Oracle database.
> So, what do you think about the performance issue.
> How big is the difference in performance between Linux and NT on the
> same hardware.
> How big difference between NT and Sun Solaris on similar cost hardware?
> Where is the bottleneck? Memory / CPU?
> 
> Hope you guys with experience of this kind of systems will answer...
> I know Linux is the best price / performance, but I don't have time to
> run and support those servers myself.
> If you think Linux is outstanding, I can maybe push those guys to learn
> it.
> 

We have customers running all three of these environments, and all perform
well. We have done some comparative performance testing and there are some
numbers in section 23.0 of the Radiator reference manual. There are also some
descriptions of a few customer installations at the following URL:

http://www.open.com.au/radiator/examples.html

On this same topic we are still looking to add more examples to this page so if
anyone else would like to contribute a description of their system, please send
it directly to me (with a note stating if you want it to be anonymous or not).

regards

Hugh

-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, 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 issue with Radiator & MS-SQL

[Hugh Irvine]

Hello Jonathon -

On Mon, 27 Dec 1999, Jonathan Ng wrote:
> 
> I've installed Radiator v2.1.4 and Radmin v1.3 on one NT Server, and MS
> SQL on another NT Server.   Both servers are based on PIII-500MHz with
> 256MB RAM and SCSI disk.
> 
> I measured the average throughput with the following command:
> 
> radpwtst -iterations 1000 -noacct -user john -password hello -time
> 
> The best number I could get is around 12 transactions per sec.   The NT
> server running Radiator is only 20% utillized for CPU.   The NT server
> running MS-SQL is around 50% utlitilzed for CPU.   It seems a bit low to
> me.
> 
> The interesting part is when I keep on running the radpwtst above, the
> number will keep on going down to around 5 tps.   However, whenever I
> stop and restart Radiator, the performance number will go back up to 12
> tps, and then degrade again.  Is that indicative of some issue with
> Radiator configuration?
> 

If you are running radpwtst on the same system as Radiator, there will also be
some performance impact due to both programs executing simultaneously. To get a
better indication you should separate the processing to different hosts.

hth

Hugh

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
NT, Rhapsody

===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

RE: (RADIATOR) performance issue with Radiator & MS-SQL

[Jonathan Ng]

Hello Mike,

I'm currently using Microsoft SQL v7 already.   I've also ran the MS-SQL v7 index tuning wizard, and it did not find any optimizations.

When I set up the database on MS-SQL, I'm just using createdb script that came with RAdmin, and I hope that's OK.

The puzzling part is whenever I stop and restart Radiator on NT, the TPS would go back up to 12 and then degrade back down to 4 again quickly after several thousands AUTH requests.   Would that imply any kind of memory leaks, etc. with the specific combination of Radiator/ACTIVESTATE PERL/NT/ODBC ?   Are you aware of any successful high performance deployment of Radiator on a NT and MS-SQL based configuration?

By the way, the supplier of ActiveState Perl is also selling something called PerlEx which will accelerate PERL performance on NT.   Would that help?

Thanks for help.

Cheers

> -Original Message-
> From: Mike McCauley [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 28, 1999 8:19 AM
> To: Jonathan Ng; '[EMAIL PROTECTED]'
> Subject: Re: (RADIATOR) performance issue with Radiator & MS-SQL
> 
> 
> Hello Jonathan,
> 
> On Dec 26,  4:41pm, Jonathan Ng wrote:
> > Subject: (RADIATOR) performance issue with Radiator & MS-SQL
> >
> > I've installed Radiator v2.1.4 and Radmin v1.3 on one NT 
> Server, and MS
> > SQL on another NT Server.   Both servers are based on 
> PIII-500MHz with
> > 256MB RAM and SCSI disk.
> >
> > I measured the average throughput with the following command:
> >
> > radpwtst -iterations 1000 -noacct -user john -password hello -time
> >
> > The best number I could get is around 12 transactions per 
> sec.   The NT
> > server running Radiator is only 20% utillized for CPU.  
> The NT server
> > running MS-SQL is around 50% utlitilzed for CPU.   It seems 
> a bit low to
> > me.
> >
> > The interesting part is when I keep on running the radpwtst 
> above, the
> > number will keep on going down to around 5 tps.   However, 
> whenever I
> > stop and restart Radiator, the performance number will go 
> back up to 12
> > tps, and then degrade again.  Is that indicative of some issue with
> > Radiator configuration?
> 
> Given those figures, I think that the limiting factor is in 
> the MS-SQL server.
> Before migrating to 7.0 as Tim Minchin suggests, I would be 
> inclined to check
> whether the indexes in the tables your Radiator accesses are OK.
> 
> >
> > I would like to find out if the above results are typical, 
> and what are
> > the numbers that others are observing on a NT-based setup 
> using MS-SQL.
> 
> On such boxes, I would expect to see considerably better performance.
> 
> Cheers.
> 
> -- 
> Mike McCauley   [EMAIL PROTECTED]
> Open System Consultants Pty. Ltd    Unix, 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, etc etc on Unix, Win95/8, 
> NT, Rhapsody
> ===
> Archive at http://www.thesite.com.au/~radiator/
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
> 

Re: (RADIATOR) performance issue with Radiator & MS-SQL

[Mike McCauley]

Hello Jonathan,

On Dec 26,  4:41pm, Jonathan Ng wrote:
> Subject: (RADIATOR) performance issue with Radiator & MS-SQL
>
> I've installed Radiator v2.1.4 and Radmin v1.3 on one NT Server, and MS
> SQL on another NT Server.   Both servers are based on PIII-500MHz with
> 256MB RAM and SCSI disk.
>
> I measured the average throughput with the following command:
>
> radpwtst -iterations 1000 -noacct -user john -password hello -time
>
> The best number I could get is around 12 transactions per sec.   The NT
> server running Radiator is only 20% utillized for CPU.   The NT server
> running MS-SQL is around 50% utlitilzed for CPU.   It seems a bit low to
> me.
>
> The interesting part is when I keep on running the radpwtst above, the
> number will keep on going down to around 5 tps.   However, whenever I
> stop and restart Radiator, the performance number will go back up to 12
> tps, and then degrade again.  Is that indicative of some issue with
> Radiator configuration?

Given those figures, I think that the limiting factor is in the MS-SQL server.
Before migrating to 7.0 as Tim Minchin suggests, I would be inclined to check
whether the indexes in the tables your Radiator accesses are OK.

>
> I would like to find out if the above results are typical, and what are
> the numbers that others are observing on a NT-based setup using MS-SQL.

On such boxes, I would expect to see considerably better performance.

Cheers.

-- 
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, etc etc on Unix, Win95/8, 
NT, Rhapsody
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Re: (RADIATOR) performance issue with Radiator & MS-SQL

[tom minchin]

On Sun, Dec 26, 1999 at 04:41:33PM -0500, Jonathan Ng wrote:
> I've installed Radiator v2.1.4 and Radmin v1.3 on one NT Server, and MS
> SQL on another NT Server.   Both servers are based on PIII-500MHz with
> 256MB RAM and SCSI disk.
> 

If you're game, you upgrade to SQL 7 (you don't mention which version you're
running) it's a bit faster but you descend into the MS proprietry interface
pit.

Alternatively, if you think Radiator is the bottleneck (may well be) you
can run multiple Radiators (eg one for Auth and one for Accounting).

Benchmarks in the manual seem to suggest (eg Platypus) you should be able
to get a few more TPS.

[EMAIL PROTECTED]

===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Re: (RADIATOR) Performance

[Mike McCauley]

Hello Dat
I would expect to see better performance than that on those boxes. Some
comments:

1. If the Ultra-2 enterprise has a faster processor then I would expect
Radiator to be faster too. Perhaps you should be sure that you are not actually
measuring the performance of radpwtst rather than Radiator: radpwtst requires a
significant number of cycles too, and I would suggest you run it on a separate
(faster) box if you can.

2. The default configuration file radius.cfg that is shipped with Radiator has
all the bells and whistles turned on, and it is definitely not streamlined for
performance (it does multiple meaningless username rewrites, has lots of
debugging turned on etc.)

3. related to 2 above there are a number of tips in the reference manual for
tuning performance that you may want to consult.

Hope that helps.

Cheers.


On Mar 12,  4:11pm, Dat Duong wrote:
> Subject: (RADIATOR) Performance
> Radiator is a pretty good product and it is very flexible.  The performance
> is not too good though ?? I've tried to push Radiator both on my ultra-10
> and ultra-enterprise 2 and in both case I cannot pass ~40 tps and the
> CPU go to 99%.  There is very litte difference between an ultra-2 enterprise
> and ultra 10 (the ultra -2 should do at least 3 X better).  The user database
> used is the sample shipped witth the product so it has very few entries.
> Am I doing something wrong here or it just the way Radiator works.
> Dat
>
> ===
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
>-- End of excerpt from Dat Duong



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

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, external, etc etc on Unix, Win95/8, NT, Rhapsody
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Re: (RADIATOR) Performance

[Dat Duong]

Date sent:  Fri, 12 Mar 1999 22:49:30 +0100
From:   Vincent Gillet <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject:        Re: (RADIATOR) Performance

> [EMAIL PROTECTED] disait :
> 
> > Radiator is a pretty good product and it is very flexible.  The performance
> > is not too good though ?? I've tried to push Radiator both on my ultra-10
> > and ultra-enterprise 2 and in both case I cannot pass ~40 tps and the
> > CPU go to 99%.  There is very litte difference between an ultra-2 enterprise
> > and ultra 10 (the ultra -2 should do at least 3 X better).  The user database
> > used is the sample shipped witth the product so it has very few entries.
> > Am I doing something wrong here or it just the way Radiator works.
> 
> It works with few CPU on a Linux box that is much less powerfull that your
> sparc.
> We have 20 or 30 req/second with more than 200,000 entry in flat file using
> DB_File  You must have a problem in Perl I guess ...
> Do you use DB_File or Ascii file ?
> 
> You may try a config with ASCII file only.
> DB or dbm may have a bug on you Sparc.
> I suggest to compile DB and Perl and not to use the one included in Solaris.
> 
No. I use the regular ASCII user file.
> Regards,
> 
> -- 
> Vincent Gillet  E-mail: [EMAIL PROTECTED]
> Oleane
> Paris La défense
> France


Dat

ÿ
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Re: (RADIATOR) Performance

[Vincent Gillet]

[EMAIL PROTECTED] disait :

> Radiator is a pretty good product and it is very flexible.  The performance
> is not too good though ?? I've tried to push Radiator both on my ultra-10
> and ultra-enterprise 2 and in both case I cannot pass ~40 tps and the
> CPU go to 99%.  There is very litte difference between an ultra-2 enterprise
> and ultra 10 (the ultra -2 should do at least 3 X better).  The user database
> used is the sample shipped witth the product so it has very few entries.
> Am I doing something wrong here or it just the way Radiator works.

It works with few CPU on a Linux box that is much less powerfull that your
sparc.
We have 20 or 30 req/second with more than 200,000 entry in flat file using
DB_File  You must have a problem in Perl I guess ...
Do you use DB_File or Ascii file ?

You may try a config with ASCII file only.
DB or dbm may have a bug on you Sparc.
I suggest to compile DB and Perl and not to use the one included in Solaris.

Regards,

-- 
Vincent Gillet  E-mail: [EMAIL PROTECTED]
Oleane
Paris La défense
France

===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.