[sr-dev] RLS performance

Anca Vamanu anca.vamanu at 1and1.ro
Fri Mar 30 10:05:40 CEST 2012


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
>
>




More information about the sr-dev mailing list