Re: [RADIATOR] Radiator AAA stats

2017-08-01 Thread Christian Kratzer

Hi Rohan,

On Mon, 31 Jul 2017, rohan.henry cwjamaica.com wrote:

Hello Christian,

I am using MySQL backend. Not seeing any timeout/delay for dbi connections.


of course not.  Radiator is synchronously feeding AuthSQL with queries and they 
are taking just as long as they take.

What you are seeing are packet drops as radiator is not popping new requests 
from the udp input queue fast enough.

Depending on what kind of authentication you are doing you might just set 
FarmSize to perhaps 8 to get 8 parallel workers.

If you are using something like EAP this won't work as requests always have to 
go the same backend.  In that you case you would setup a frontend radiator with 
AuthBy HASHBALANCE or similar and feed the requests to backend doing the EAP 
and SQL auth.

There are countless other options.

What exactly is the best option is impossible to say without furhter details.

A config of what you are attempting would help a lot.  Also knowing if how long 
your queries are taking and if they are fully utilizing the indexes etc... in 
the db.

Greetings
Christian




Regards,
Rohan

Regards,
Rohan

- Original Message -
From: "Christian Kratzer" <ck-li...@cksoft.de>
To: "Rohan Henry" <rohan.he...@cwjamaica.com>
Cc: "Hugh Irvine" <h...@open.com.au>, "radiator" <radiator@lists.open.com.au>
Sent: Monday, July 31, 2017 9:45:14 AM
Subject: Re: [RADIATOR] Radiator AAA stats

Hi Rohan,

On Mon, 31 Jul 2017, rohan.henry cwjamaica.com wrote:

Thanks Hugh,

We are considering additional VMs or radiator instances.


in some cases with a high latency backend adding additional processes can work 
wonders.

That is if the backend is able to keep up with the throughput but just has high 
latency.

There are several ways to intelligently increases parallelity in radiator.

I did not see any details on what exactly your are using radiator for and what 
kind of backends you are using.

Greetings
Christian



Regards,
Rohan

- Original Message -
From: "Hugh Irvine" <h...@open.com.au>
To: "Rohan Henry" <rohan.he...@cwjamaica.com>, "Heikki Vatiainen" 
<h...@open.com.au>
Cc: "radiator" <radiator@lists.open.com.au>
Sent: Wednesday, July 26, 2017 3:15:31 PM
Subject: Re: [RADIATOR] Radiator AAA stats

Hello Rohan -

In addition to this you should look at a trace 4 debug from Radiator with 
LogMicroseconds enabled.

This will show you the timestamps for each processing step and you will see 
exactly where you are spending time.

If your overall processing from Access-Request receive to Access-Accept being 
sent is say 50 milliseconds, it therefore follows that this instance will only 
be able to handle at most 20 requests per second.

YMMV of course, and this depends greatly on how you have set up your overall 
system.

BTW - I always recommend at the very least running separate instances for 
authentication and accounting.

reagrds

Hugh


On 27 Jul 2017, at 05:17, Heikki Vatiainen <h...@open.com.au> wrote:

On 21.07.2017 17:59, rohan.henry cwjamaica.com wrote:


How do I confirm or calculate the number of concurrent requests a single 
Radiator instance can handle?


It's hard to say how to calculate this. It depends on what the instance is 
configured to do. For example, if it has to proxy requests, you are likely 
going to be bounded by CPU performance. If there are database lookups, the 
instance may need to wait DB responses while its CPU utilisation stays low.


How can I view stats to know when the instance is nearing capacity?


I'd watch CPU utilisation and UDP receive errors (netstat -u -s). The UDP 
receive errors increase if the receive buffer fills up and the kernel has to 
start dropping incoming Radius UDP messages.

If Radiator logs that it is receiving duplicate requests, this may indicate 
that the client is not getting responses as quickly as it needs (or the 
responses are dropped between Radiator and the client). The duplicates may 
indicate that there are problems handling the requests in timely manner.

Depending on your configuration there can be other indicators too, but the 
above should give a starting point.

Thanks,
Heikki

--
Heikki Vatiainen <h...@open.com.au>
___
radiator mailing list
radiator@lists.open.com.au
http://lists.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@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiat

Re: [RADIATOR] Radiator AAA stats

2017-07-31 Thread rohan.henry cwjamaica.com
Hello Christian,

I am using MySQL backend. Not seeing any timeout/delay for dbi connections.

Regards,
Rohan

Regards,
Rohan

- Original Message -
From: "Christian Kratzer" <ck-li...@cksoft.de>
To: "Rohan Henry" <rohan.he...@cwjamaica.com>
Cc: "Hugh Irvine" <h...@open.com.au>, "radiator" <radiator@lists.open.com.au>
Sent: Monday, July 31, 2017 9:45:14 AM
Subject: Re: [RADIATOR] Radiator AAA stats

Hi Rohan,

On Mon, 31 Jul 2017, rohan.henry cwjamaica.com wrote:
> Thanks Hugh,
>
> We are considering additional VMs or radiator instances.

in some cases with a high latency backend adding additional processes can work 
wonders.

That is if the backend is able to keep up with the throughput but just has high 
latency.

There are several ways to intelligently increases parallelity in radiator.

I did not see any details on what exactly your are using radiator for and what 
kind of backends you are using.

Greetings
Christian

>
> Regards,
> Rohan
>
> - Original Message -
> From: "Hugh Irvine" <h...@open.com.au>
> To: "Rohan Henry" <rohan.he...@cwjamaica.com>, "Heikki Vatiainen" 
> <h...@open.com.au>
> Cc: "radiator" <radiator@lists.open.com.au>
> Sent: Wednesday, July 26, 2017 3:15:31 PM
> Subject: Re: [RADIATOR] Radiator AAA stats
>
> Hello Rohan -
>
> In addition to this you should look at a trace 4 debug from Radiator with 
> LogMicroseconds enabled.
>
> This will show you the timestamps for each processing step and you will see 
> exactly where you are spending time.
>
> If your overall processing from Access-Request receive to Access-Accept being 
> sent is say 50 milliseconds, it therefore follows that this instance will 
> only be able to handle at most 20 requests per second.
>
> YMMV of course, and this depends greatly on how you have set up your overall 
> system.
>
> BTW - I always recommend at the very least running separate instances for 
> authentication and accounting.
>
> reagrds
>
> Hugh
>
>> On 27 Jul 2017, at 05:17, Heikki Vatiainen <h...@open.com.au> wrote:
>>
>> On 21.07.2017 17:59, rohan.henry cwjamaica.com wrote:
>>
>>> How do I confirm or calculate the number of concurrent requests a single 
>>> Radiator instance can handle?
>>
>> It's hard to say how to calculate this. It depends on what the instance is 
>> configured to do. For example, if it has to proxy requests, you are likely 
>> going to be bounded by CPU performance. If there are database lookups, the 
>> instance may need to wait DB responses while its CPU utilisation stays low.
>>
>>> How can I view stats to know when the instance is nearing capacity?
>>
>> I'd watch CPU utilisation and UDP receive errors (netstat -u -s). The UDP 
>> receive errors increase if the receive buffer fills up and the kernel has to 
>> start dropping incoming Radius UDP messages.
>>
>> If Radiator logs that it is receiving duplicate requests, this may indicate 
>> that the client is not getting responses as quickly as it needs (or the 
>> responses are dropped between Radiator and the client). The duplicates may 
>> indicate that there are problems handling the requests in timely manner.
>>
>> Depending on your configuration there can be other indicators too, but the 
>> above should give a starting point.
>>
>> Thanks,
>> Heikki
>>
>> --
>> Heikki Vatiainen <h...@open.com.au>
>> ___
>> radiator mailing list
>> radiator@lists.open.com.au
>> http://lists.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@lists.open.com.au
> http://lists.open.com.au/mailman/listinfo/radiator
>

-- 
Christian Kratzer   CK Software GmbH
Email:   c...@cksoft.de   Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0   D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9   HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843   Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/

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


Re: [RADIATOR] Radiator AAA stats

2017-07-31 Thread rohan.henry cwjamaica.com
Thanks Hugh,

We are considering additional VMs or radiator instances.

Regards,
Rohan

- Original Message -
From: "Hugh Irvine" <h...@open.com.au>
To: "Rohan Henry" <rohan.he...@cwjamaica.com>, "Heikki Vatiainen" 
<h...@open.com.au>
Cc: "radiator" <radiator@lists.open.com.au>
Sent: Wednesday, July 26, 2017 3:15:31 PM
Subject: Re: [RADIATOR] Radiator AAA stats

Hello Rohan -

In addition to this you should look at a trace 4 debug from Radiator with 
LogMicroseconds enabled.

This will show you the timestamps for each processing step and you will see 
exactly where you are spending time.

If your overall processing from Access-Request receive to Access-Accept being 
sent is say 50 milliseconds, it therefore follows that this instance will only 
be able to handle at most 20 requests per second.

YMMV of course, and this depends greatly on how you have set up your overall 
system.

BTW - I always recommend at the very least running separate instances for 
authentication and accounting.

reagrds

Hugh

> On 27 Jul 2017, at 05:17, Heikki Vatiainen <h...@open.com.au> wrote:
> 
> On 21.07.2017 17:59, rohan.henry cwjamaica.com wrote:
> 
>> How do I confirm or calculate the number of concurrent requests a single 
>> Radiator instance can handle?
> 
> It's hard to say how to calculate this. It depends on what the instance is 
> configured to do. For example, if it has to proxy requests, you are likely 
> going to be bounded by CPU performance. If there are database lookups, the 
> instance may need to wait DB responses while its CPU utilisation stays low.
> 
>> How can I view stats to know when the instance is nearing capacity?
> 
> I'd watch CPU utilisation and UDP receive errors (netstat -u -s). The UDP 
> receive errors increase if the receive buffer fills up and the kernel has to 
> start dropping incoming Radius UDP messages.
> 
> If Radiator logs that it is receiving duplicate requests, this may indicate 
> that the client is not getting responses as quickly as it needs (or the 
> responses are dropped between Radiator and the client). The duplicates may 
> indicate that there are problems handling the requests in timely manner.
> 
> Depending on your configuration there can be other indicators too, but the 
> above should give a starting point.
> 
> Thanks,
> Heikki
> 
> -- 
> Heikki Vatiainen <h...@open.com.au>
> ___
> radiator mailing list
> radiator@lists.open.com.au
> http://lists.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@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator


Re: [RADIATOR] Radiator AAA stats

2017-07-31 Thread rohan.henry cwjamaica.com
Thanks Heikki,

UDP receive errors are climbing and there are duplicate requests.

Regards,
Rohan

- Original Message -
From: "Heikki Vatiainen" <h...@open.com.au>
To: "radiator" <radiator@lists.open.com.au>
Sent: Wednesday, July 26, 2017 2:17:34 PM
Subject: Re: [RADIATOR] Radiator AAA stats

On 21.07.2017 17:59, rohan.henry cwjamaica.com wrote:

> How do I confirm or calculate the number of concurrent requests a single 
> Radiator instance can handle?

It's hard to say how to calculate this. It depends on what the instance 
is configured to do. For example, if it has to proxy requests, you are 
likely going to be bounded by CPU performance. If there are database 
lookups, the instance may need to wait DB responses while its CPU 
utilisation stays low.

> How can I view stats to know when the instance is nearing capacity?

I'd watch CPU utilisation and UDP receive errors (netstat -u -s). The 
UDP receive errors increase if the receive buffer fills up and the 
kernel has to start dropping incoming Radius UDP messages.

If Radiator logs that it is receiving duplicate requests, this may 
indicate that the client is not getting responses as quickly as it needs 
(or the responses are dropped between Radiator and the client). The 
duplicates may indicate that there are problems handling the requests in 
timely manner.

Depending on your configuration there can be other indicators too, but 
the above should give a starting point.

Thanks,
Heikki

-- 
Heikki Vatiainen <h...@open.com.au>
___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator

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


Re: [RADIATOR] Radiator AAA stats

2017-07-26 Thread Hugh Irvine

Hello Rohan -

In addition to this you should look at a trace 4 debug from Radiator with 
LogMicroseconds enabled.

This will show you the timestamps for each processing step and you will see 
exactly where you are spending time.

If your overall processing from Access-Request receive to Access-Accept being 
sent is say 50 milliseconds, it therefore follows that this instance will only 
be able to handle at most 20 requests per second.

YMMV of course, and this depends greatly on how you have set up your overall 
system.

BTW - I always recommend at the very least running separate instances for 
authentication and accounting.

reagrds

Hugh

> On 27 Jul 2017, at 05:17, Heikki Vatiainen  wrote:
> 
> On 21.07.2017 17:59, rohan.henry cwjamaica.com wrote:
> 
>> How do I confirm or calculate the number of concurrent requests a single 
>> Radiator instance can handle?
> 
> It's hard to say how to calculate this. It depends on what the instance is 
> configured to do. For example, if it has to proxy requests, you are likely 
> going to be bounded by CPU performance. If there are database lookups, the 
> instance may need to wait DB responses while its CPU utilisation stays low.
> 
>> How can I view stats to know when the instance is nearing capacity?
> 
> I'd watch CPU utilisation and UDP receive errors (netstat -u -s). The UDP 
> receive errors increase if the receive buffer fills up and the kernel has to 
> start dropping incoming Radius UDP messages.
> 
> If Radiator logs that it is receiving duplicate requests, this may indicate 
> that the client is not getting responses as quickly as it needs (or the 
> responses are dropped between Radiator and the client). The duplicates may 
> indicate that there are problems handling the requests in timely manner.
> 
> Depending on your configuration there can be other indicators too, but the 
> above should give a starting point.
> 
> Thanks,
> Heikki
> 
> -- 
> Heikki Vatiainen 
> ___
> radiator mailing list
> radiator@lists.open.com.au
> http://lists.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@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator