[RADIATOR] Processing delay in Diameter

[Heikki Vatiainen]

On 28.3.2015 10.44, Arthur wrote:
> OK, it's mean that my mentioned  5.2 seconds delay example caused by
> previously slowly processed requests and OS rx buffer filling?
> I have trace 4 with LogMicroseconds logfile and I will try to analyze
> it. But due of lot of traffic it's not a easy task.

Trace 4 will slow down the performance a lot, so if you had problems 
with debugging enabled, this might be at least a partial cause too.

> Does FarmSize parameter can help in this situation with pure Diameter
> environment?

If there's only one incoming Diameter TCP connection, then FarmSize will 
not help. What would happen is that one of the workers accepts the 
connection and will then process the messages for this connection. This 
is how the connection oriented / connectionless TCP/UDP mainly differ 
with ServerFarm.

If there are multiple incoming connections, then it may (or may not) 
happen that different farm workers accept the connections. In this case 
this can help with load balancing.

If there are a number of different Diameter peers, you could set up 
multiple Radiator instances with different listen ports and then direct 
the peers to the separate instances.

Thanks,
Heikki

-- 
Heikki Vatiainen <hvn at 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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, 
NetWare etc.