[sr-dev] RLS performance

[Daniel-Constantin Mierla]

Hello,

one more thing that can be added to increase performances is using own 
timer process or a pool of timer processes -- in this way there is no 
interference with other modules using the generic timer.

There are two functions fork_basic_timer() and fork_basic_utimer() that 
can be used -- rtimer is a good example to look at for doing it.

These kind of timers don't sync back the interval -- i mean if a 
function executed on timer takes too long, the process should sleep less 
or at all to catch up, but this is easy to add if people think is important.

Cheers,
Daniel

On 3/30/12 10:05 AM, Anca Vamanu wrote:
> Hi Peter,
>
> A very nice approach. Still waiting waitn_timer for each Subscription 
> dialog but distributing the work through the whole interval. Sounds 
> good to me also.
>
> Regards,
> Anca
>
> On 03/30/2012 12:05 AM, Peter Dunkley wrote:
>> Hello,
>>
>> When under load RLS performs in a "lumpy" manner.  I believe this is (at
>> least in part) because of the waitn_timer for sending NOTIFY requests.
>>
>> This timer is needed because, as the RFCs point out, it is important to
>> buffer up RLS NOTIFY requests so as not to flood the network and client.
>> However, I was wondering if a small change might help smooth out the
>> lumps.
>>
>> What I was thinking of is:
>> - Change the updated flag to be a number between 1 and the value of
>> waitn_time (0 means no update)
>> - Set the flag number based to the core_hash(did, NULL, waitn_time-1)+1
>> when the rls_presentity record is updated/inserted
>> - Have RLS NOTIFY requests sent each second.  After the first second
>> records with the updated flag of value 1 are sent.  After the second
>> second records with the updated flag of value 2 are sent.  Wrapping back
>> to 1 after waitn_time seconds.
>>
>> This should help smooth out the sending of NOTIFY requests from RLS 
>> while
>> still making sure they are buffered and take at most waitn_time 
>> seconds to
>> come out.
>>
>> Can anybody see any reason why this won't work?
>>
>> Would there be any objections to me making this change?
>>
>> Regards,
>>
>> Peter
>>
>>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
http://www.asipto.com/index.php/kamailio-advanced-training/