[RADIATOR] Processing delay in Diameter

[Arthur]

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 situation with pure Diameter 
environment?

br,
Arthur


28.03.2015 4:59, Hugh Irvine kirjutas:
> 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 to slow responses from SQL and/or LDAP databases (or sometimes slow DNS lookups).
>
> regards
>
> Hugh
>
>
>> On 27 Mar 2015, at 19:56, Heikki Vatiainen <hvn at open.com.au> wrote:
>>
>> 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:
>>> No.    Time               Source         Destination   Protocol Length Info
>>> 231521 09:00:58.997242000 xxx.xxx.xx.xx  xxx.xxx.xx.xx DIAMETER 1622
>>> cmd=Accounting Request(271) flags=RP-- appl=Diameter Base Accounting(3)
>>> h2h=253e8654 e2e=253e8654
>>>
>>> But in the Radiator this request appears 5.2 second later:
>>> Thu Mar 26 09:01:04 2015 029052: DEBUG: StateMachine::event event
>> Most likely you see this request as delayed because there is already a
>> queue in the OS receive buffer. That is, the previous messages have
>> taken longer than than usually.
>>
>> I would take a look at the request processing flow and consider what
>> external lookups radiusd is doing. For example, DNS lookups, SQL DB
>> queries and so on. Some functions in Radius/Util.pm may do DNS lookups.
>> This can happen if they are given a name instead of IP address.
>>
>> 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.
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>
> --
>
> Hugh Irvine
> hugh 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, SIM, etc.
> Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
>