[RADIATOR] Processing delay in Diameter

[Arthur]

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