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