30.03.2015 13:05, Heikki Vatiainen kirjutas: > 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. No-no, I increase logging level for debugging only for the short period of time. Normally level 3 there. >> 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. OK, thank you for an explanation.
> > 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. > > br, Arthur _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator