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