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.
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.
Tr
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.
Does FarmSize parameter can help in this s
Hello Arthur -
The best way to see what is happening is to run Radiator at trace 4 with
LogMicroseconds enabled.
This will show you exactly how long each processing step is taking and how long
Raditor is waiting for external resources.
As Heikki says, this sort of problem is almost always due
On 26.3.2015 14.45, Kaspar Jasper wrote:
> My Diameter peer sometimes complains about Diameter timeouts, which is 5
> seconds. Debugging leads me to the interesting detail - Diameter
> messages sometimes are processing with delays in Radiator.
>
> For instance, Radiator's server Wireshark capture:
p{padding:0;margin:0;} Hello,
My Diameter peer sometimes complains about Diameter timeouts,
which is 5 seconds. Debugging leads me to the interesting detail -
Diameter messages sometimes are processing with delays in Radiator.
For instance, Radiator's server Wireshark capture:
No.
Time
