<div dir="ltr">Hi Heikki, <div><br></div><div>Thanks for your answer. Due to a routing issue on network, one database query was taking 100ms for each Radiator (we got 2) After we fix the issue, now a query takes 2 ms for the first one, for second one its 20ms. So TPS is much better now. </div><div><br></div><div>For the second one, which is taking 20ms, we will consider to use Farmsize command. </div><div><br></div><div>Thanks </div><div>Best Regards</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Heikki Vatiainen <<a href="mailto:hvn@open.com.au">hvn@open.com.au</a>>, 13 Ara 2019 Cum, 16:36 tarihinde şunu yazdı:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/12/2019 15.52, cihangir sinan koca wrote:<br>
<br>
> What we are facing is, servers are unable to process more packet than <br>
> 50-60 TPS. After i while its not writing the problem in logs, its not <br>
> answering to any packet.<br>
> <br>
> Is it expected ? Or are we doing something wrong ?<br>
<br>
I'd say it's possible and possibly not, respectively :)<br>
<br>
Database access is synchronous. If DB takes a long time to respond, it <br>
will lower TPS rate for a single Radiator instance. To fix this, you <br>
take a look at FarmSize parameter to increase the number of instances to <br>
make processing parallel.<br>
<br>
FarmSize works with protocols such as PAP, MSCHAP and its derivatives <br>
and RADIUS accounting. With EAP you need to do more because it uses <br>
multiple messages for each authentication and the related messages must <br>
be processed by the same instance.<br>
<br>
To summarise: there can be many reasons why TPS rate is low. Sometimes <br>
indexing on the DB side helps a lot, sometimes there are DNS requests <br>
for each query or it may be a number of different things such as a <br>
complex configuration that consults 3 databases for each request. You <br>
should also check that you are not using debug logging while trying to <br>
test performance.<br>
<br>
I would look at DB indexing and logs on the DB side and Radiator <br>
configuration log level and complexity on Radiator side.<br>
<br>
Thanks,<br>
Heikki<br>
<br>
-- <br>
Heikki Vatiainen <<a href="mailto:hvn@open.com.au" target="_blank">hvn@open.com.au</a>><br>
<br>
Radiator: the most portable, flexible and configurable RADIUS server<br>
anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,<br>
EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,<br>
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.<br>
_______________________________________________<br>
radiator mailing list<br>
<a href="mailto:radiator@lists.open.com.au" target="_blank">radiator@lists.open.com.au</a><br>
<a href="https://lists.open.com.au/mailman/listinfo/radiator" rel="noreferrer" target="_blank">https://lists.open.com.au/mailman/listinfo/radiator</a><br>
</blockquote></div>